Re: [PATCH v2 2/3] git-send-email: die on invalid smtp_encryption

From: Drew DeVault <sir@cmpwn.com>
Date: Apr 11, 2021, 15:18 UTC
Message-ID: <CAKZTYI6U0WY.36DC3N1E4R7D2@taiga>
In-Reply-To: <875z0sg8t9.fsf@evledraar.gmail.com>

On Sun Apr 11, 2021 at 11:06 AM EDT, Ævar Arnfjörð Bjarmason wrote:

Show 10 quoted lines

> 3. While I'm very much leaning to #1 being a good idea, I'm very much
> leaning towards introducing this "starttls" alias being a bad idea
> for the same reason.
>     
> i.e. let's not create a new 'starttls' if we can avoid it explicitly
> because we used to have the long-standing "anything unrecognized is
> empty == no encryption" behavior.
>
> A lot of users read documentation for the latest version online, but
> may have an older version installed.

I feel quite strongly that the options here are a grave failure of usability, and that it needs to be corrected. I help people troubleshoot git send-email problems quite often, and this is a recurring error. However, you make a good point in that someone might see some online documentation which does not match their git version and end up with a surprisingly unencrypted connection.

As a compromise, let's consider making this a gradual change. We can start by clarifying the docs and forbiding the use of any value other than 'ssl' or 'tls'. If an unknown value is set, the user is not getting the encryption they expected anyway, and this should cause an error.

Then we can leave the issue aside for some agreed upon period of time to allow the change to proliferate in the ecosystem, and then revisit this at some point in the future to rename the options to make more sense.

Does this seem like a reasonable compromise?