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

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.

openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to