On Fri Apr 9, 2021 at 8:52 PM EDT, Junio C Hamano wrote: > Hmph. > > Isn't SMTPS (running SMTP over SSL encrypted connection) the one > that was once deprecated until it got resurrected)? Kind of, back in the 90's, but that's water under the bridge now. SMTP over SSL/TLS is the de-facto standard. > STARTTLS is not all that SMTP specific---POP and IMAP can also start > in cleartext and upgrade with STARTTLS the same way, no? Well, email-specific, at least. Sorry for the confusion. > I couldn't find a justification for our log message to call > STARTTLS-style explicit TLS "deprecated". When you send an updated > version, please give a reference. The main concern with STARTTLS is downgrade attacks. I'll note this in the commit message for v2. > I think it is a vast improvement to describe what existing 'ssl' and > 'tls' does, like the above does. It is a documentation update that > deserves its own commit (i.e. [PATCH 1/3]), and it should be done > before adding the new ssl/tls and starttls synonyms. > > Making it an error to give unrecognised string (i.e. other than > 'ssl' and 'tls'), or at least warning, would be a good follow-up > change (i.e. [PATCH 2/3]), but that is optional. > > And then, it may make sense to introduce the synonyms, but please > make it a separate patch that builds on top of the other two steps > (i.e. [PATCH 3/3]). Ack, can do. > In the ideal world, it would have been nice if we could make 'tls' > as the name of the choice that has been known as 'ssl' (i.e. the > underlying transport protocol to run SMTP or any other higher layer > protocol on top, there used to be SSL but these days TLS is used as > an improved alternative---SSL 2.0/3.0 have been deprecated for some > time), but because we used 'tls' to mean the STARTTLS-style "start > SMTP as plain and then upgrade to encrypted channel", we can't reuse > the 'tls' for that purpose. > > I do not have any qualm about the fully spelled out "starttls" > synonym for the latter. In fact, if we can go back in time and redo > the history with hindsight, that is the name we should have used > from the beginning. But I find it unfortunate that we need to say > 'ssl/tls', i.e. prefixing the name of the choice with the name of a > deprecated thing, for the former. Another reason I am hesitant > about 'ssl/tls' is because the description of it in documentation > naturally invites errors. I.e. "You can set it to 'ssl/tls'..." > sounds as if the manual is telling me to use one of 'ssl' or 'tls', > which is not what it is sayng---it literally wants me to say > 'ssl/tls' with a slash in it. If I may propose a bold alternative: what I added as "ssl/tls", i.e. "modern" SSL, should be "yes", no encryption should be "no", and if you specifically need starttls: "starttls".
