Support self-signed certificates for remote taskfiles

[pd93]

Description

As reported in #1317 (comment), Task cannot currently access remote taskfiles using self-signed certificates. We have the --insecure flag which allows you to access files over HTTP (no-tls), but no flag for skipping TLS verification over HTTPS or for specifying paths to a custom key/cert.

Here are some examples of equivalent flags in other popular CLI tools:

	curl	wget	httpie	task
Allow connections over HTTP	allowed by default	allowed by default	allowed by default	--insecure
No cert verification over HTTPS	--insecure/-k	--no-check-certificate	--verify=no	-
Custom CA cert path	--cacert	--ca-certificate	--verify=<path>	-
Custom cert path	--cert/-E	--certificate	--cert	-
Custom key path	--key	--private-key	--cert-key	-
Custom cert passphrase	--pass *	-	--cert-key-pass	-

* curl also allows you to specify a passphrase by --cert/-E <certificate[:password]>

Proposal

Since we already have the --insecure flag, I don't see the harm in reusing this to disable TLS verification for HTTPS requests. This keeps us consistent with cURL and means we don't have two flags that do similar things reducing confusion.

For custom certs, I propose we add the following flags:

• --cacert for specifying a custom CA cert path
• --cert for specifying a custom cert path
• --cert-key for specifying a custom key path
• --cert-key-pass for specifying a custom cert passphrase

This is a mix between the flags in cURL and HTTPie. I think the namespacing for the cert flags is important as it leaves scope to create other flags with similar names in the future (e.g. if something else might need a password). However, I think the --insecure and --cacert flags are more familiar (at least to me) and more intuitive than HTTPie's multiuse --verify.

cURL does have a bit of syntactic sugar in that you can specify the passphrase inside the --cert flag and it will also detect the key/cert in the same file. But this seems unnecessary for a first implementation.

[pfeigl]

As a windows user, one thing extremly important to me would be, that the standard windows certificate store is used (ideally by default).

As far as I know this should be the case in Go, but can be disabled as soon as custom CA settings are defined.