From: Jeff King <peff@peff.net>
Date: Wed, 15 Feb 2012 22:06:29 GMT
Subject: Re: [PATCH] git-send-email: allow overriding smtp-encryption config to 'none'
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:

> 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