Re: [PATCH] git-send-email: allow overriding smtp-encryption config to 'none'

From: Jeff King <peff@peff.net>
Date: Feb 15, 2012, 22:06 UTC
Message-ID: <20120215220629.GA17672@sigill.intra.peff.net>
In-Reply-To: <1329342178-14540-1-git-send-email-computersforpeace@gmail.com>

On Wed, Feb 15, 2012 at 01:42:58PM -0800, Brian Norris wrote:

Show 10 quoted lines

> According to the manpage:
> 
>  --smtp-encryption=<encryption>
>         Specify the encryption to use, either ssl or tls. Any other value
> 	reverts to plain SMTP.  Default is the value of
>         sendemail.smtpencryption.
> 
> However, if I have already set sendemail.smtpencryption but try to override
> it with something like 'no', the authentication code block still tries to ask
> for a password (and fails).

Sounds reasonable.

> This patch forces $smtp_encryption to 'none' when a proper encryption type is
> not provided, then checks $smtp_encryption before proceeding to authentication.

Defaulting everything except "ssl" or "tls" to "none" seems risky to me. If I am understanding your patch correctly, then doing this:

  git send-email --smtp-encryption=SSL

will silently treat that as "don't do encryption", which could have surprising security implications for the user. I chose all-caps as it is an obvious mistake to make. We probably should treat it the same as lowercase "ssl", but the same argument applies to other typos like "tsl".

It seems like a much safer default would be to die() on an invalid encryption specifier.

-Peff