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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 13, 2021, 21:39 UTC
Message-ID: <xmqqtuo9kgo0.fsf@gitster.g>
In-Reply-To: <CAML4RYHKQ6U.35902JHAIZYY@taiga>

"Drew DeVault" <sir@cmpwn.com> writes:

> Can I get one of the maintainers to chime in on this thread and explain,
> in their opinion, what this patchset needs before it is acceptable? I'm
> not sure where I should go from this discussion.

What you called "compromise" in the upthread didn't even smelled like a compromise but the safest way forward. My reasoning goes (thinking aloud, so that you and Ævar can correct me if I am talking nonsense and discount my input based on it):

 - If we were designing this from scratch, we would have called the
   smtps:// tunnelled transport SSL/TLS and in-place upgrade
   transport STARTTLS, like e-mail providers and client programs do,
   but unfortunately we didn't.  We ended up with 'ssl' vs 'tls'.

 - We could introduce and advertise STARTTLS as a synonym to 'tls',
   but then those whose send-email does not understand STARTTLS but
   read about the new way of spelling would end up having no
   encryption due to another earlier mistake we made, i.e. an
   unrecognised option value silently turns into no encryption.

 - To avoid the above problem, the first phase is not to change the
   status quo that 'ssl' vs 'tls' are the only two choices.  What we
   do is to make the program error out if we see an unrecognised
   value given to the option.  We release this to the wild, and wait
   for the current versions of send-email that turns unrecognised
   words into no-encryption die out.  It may take several years,
   though.

 - After waiting, we add 'starttls' as a synonym to 'tls'.  We may
   also add 'ssl/tls' as a synonym to 'ssl'.  Unfortunately 'tls'
   alone cannot be repurposed as a synonym for smtps:// without
   another deprecation dance, and it is not in scope of the
   transtion.

Am I on the same page as you two?