John Keeping <john@xxxxxxxxxxxxx> writes:
> I'd rather have '$smtp_ssl_cert_path ne ""' in the first if condition
> (instead of the '-d $smtp_ssl_cert_path') ...
I agree. The signal for "no certs" should be an explicit "nonsense"
value like an empty string, not just a string that does not name an
expected filesystem object. Otherwise people can misspell paths and
disable the validation by accident.
> Perhaps a complete solution could allow CA files as well.
Yes, that would be a good idea. Care to roll into a "fixup!" patch
against [2/2]?
> if (defined $smtp_ssl_cert_path) {
> if ($smtp_ssl_cert_path eq "") {
> return (SSL_verify_mode => SSL_VERIFY_NONE);
> } elsif (-f $smtp_ssl_cert_path) {
> return (SSL_verify_mode => SSL_VERIFY_PEER,
> SSL_ca_file => $smtp_ssl_cert_path);
> } else {
> return (SSL_verify_mode => SSL_VERIFY_PEER,
> SSL_ca_path => $smtp_ssl_cert_path);
> }
> } else {
> return (SSL_verify_mode => SSL_VERIFY_PEER);
> }
Two things that worry me a bit are:
(1) At the end user UI level, it may look nice to accept some form
of --no-option-name to say "I have been using SSL against my
server with handrolled cert, and I want to keep using the
verify-none option"; "--ssl-cert-path=" looks somewhat ugly.
The same goes for [sendemail] ssl_cert_path = "" config.
(2) How loudly does the new code barf when no configuration is done
(i.e. we just pass SSL_VERIFY_PEER and let the system default
CA path to take effect) and the server cert does not validate?
The warning that triggered this thread, if we had the
configuration mechanism we have been designing together, would
have been a good reminder for the user to use it, but would we
give a similar (less noisy is fine, as long as it is clear)
diagnostic message?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html