Security: don't print provided HTTP header value as part of help info

[sanmai-NL]

Printing the actual provided HTTP request header is not needed to help the user. But it does add an information leak in logs. I think that a custom header in most applications of Lychee in practice, would contain sensitive values.

Actual behavior

$ read gitlabtoken
read> glpat-SECRET
$ lychee --header "PRIVATE-TOKEN=$gitlabtoken" https://gitlab.com/mysecretproject
Error: Header value must be of the form key=value, got PRIVATE-TOKEN: glpat-SECRET

Desired behavior

$ read gitlabtoken
read> glpat-SECRET
$ lychee --header "PRIVATE-TOKEN=$gitlabtoken" https://gitlab.com/mysecretproject
Error: Header value must be of the form key=value.

[sanmai-NL]

Note that in the previous example, the secret token is provided on the command line, rather than read as a secret. This also a security antipattern, since it leaks secrets to the shell logs. An additional enhancement would be to allow header specification in a file (not a configuration file, useful to be shareable and with non-sensitive content).

[sanmai-NL]

Given #1298, this issue could be quick-fixed by keeping the current functionality intact but warning in the docs and UI that this parameter should never be used for secrets and for values that are host specific.

Alternatively, if that explicit feature scope seems too limiting, the feature could be deprecated in favor of the solution for #1298.

[mre]

I like it.

• Change error message in

  lychee/lychee-bin/src/parse.rs

  Line 11 in b882a14

  "Header value must be of the form key=value, got {}",

We should also add #1298, but we can discuss that over there.