Support self-signed certificates for remote taskfiles
Description
As reported in https://github.com/go-task/task/issues/1317#issuecomment-2848743078, 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:
--cacertfor specifying a custom CA cert path--certfor specifying a custom cert path--cert-keyfor specifying a custom key path--cert-key-passfor 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.
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.
@pd93, do you work on that? I would love to have this implemented, mostly the --insecure part. May I offer my help and create a PR for that?
Hello @maciej-lech I've already opened a PR https://github.com/go-task/task/pull/2537
@vmaerten great to hear. I'm looking forward to have it released