<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 02/13/2017 10:13 AM, Matt Caswell wrote:<br>
<blockquote
cite="mid:11f76d24-e482-e6d5-0408-85be5611f918@openssl.org"
type="cite">
<pre wrap="">
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)?
</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
-Ben<br>
</body>
</html>