Re: openssl 1.1.1 in stretch backports?
On Mon, 14 Jan 2019 at 09:11:21 +0100, Harald Dunkel wrote:
> On 1/11/19 10:23 PM, Benjamin Kaduk wrote:
> > On Fri, Jan 11, 2019 at 01:56:35PM +0100, Harald Dunkel wrote:
> > > Is it possible to use openssl 1.1.1 as a drop-in replacement for
> > > 1.1.0?
> >
> > Well ... mostly. It's *supposed* to be, but there are some places where
> > behavior had to change to get TLS 1.3 support, and some of those changes
> > are on the boundary of "breaks functioning code" and "your code was doing
> > unsupported/undocumented things". (Unfortunately, I don't have any
> > examples off the top of my head.)
>
> If there are important changes (like introducing TLS 1.3 or others,
> modifying the api), isn't it custom to change the SONAME, making sure
> that shared objects for old and new api can be installed in parallel?
If a change is definitely incompatible, then the SONAME must change.
However, if a change is backwards-compatible, then the SONAME should
stay the same, so that existing applications can benefit from the changes
without recompilation, and to minimize the chance that both the old and
the new SONAME end up indirectly linked into the same process space
via library dependencies (which usually results in crashes or other
undefined behaviour).
When a change is close to the borderline between compatible and
incompatible (for example if it can break existing code that was doing
something that was already considered to be wrong), then whether the
SONAME is changed is a matter of upstream release management, balancing
the need to provide parallel-installation of incompatible libraries
against the advantages of keeping the same SONAME. Different upstreams
apply more or less strict criteria for what changes they will consider
to be backwards-compatible, depending on how they balance those factors.
smcv
Reply to: