On 02/13/2017 10:13 AM, Matt Caswell wrote: > I was targeting this change for 1.1.1. The issue is that this does > change command line behaviour between minor versions of the 1.1.x series > - which is supposed to preserve API and ABI compatibility. Of course > this change affects neither API or ABI as its in the apps only - > although we usually extend that compatibility to try to ensure that > command line behaviour remains stable too. > > You could argue that the only change in behaviour here is the addition > of an extension by default that wasn't there before - and that we've > already decided to add new extensions in 1.1.1 due to the forthcoming > TLSv1.3 support. On the other hand you could argue that this could break > existing scripts that rely on the current SNI behaviour. > > So the question is: should this (type of) change be allowed in a 1.1.x > release? Or should it only be allowed in some future 1.2.0 (or not at all)? >
A few thoughts: I agree that the ecosystem is moving towards using SNI almost all of the time, and this change is probably net helpful to our users. However, it is also the sort of change that I would have expected to be blocked by the ABI stability promise (as I understand it to be, or maybe as I imagine it to be in my wishful thinking). In this particular case, my personal opinion is that the benefit outweighs the compatibility breakage, but I could sympathize with someone who felt differently. Perhaps a reasonable compromise would be to ensure that the -noservername option is accepted (as a noop) in 1.1.0<letter>, so that there is a way to write a script that remains compatible between 1.1.0 and 1.1.1 even if the default does change. -Ben
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
