[openssl-project] The problem of (implicit) relinking and changed behaviour

[Paul Dale]

I’m for ABI compatibility going forward (but not necessarily backwards) and for testing it, preferably in a CI loop.

 

I know I’m late to the discussion but it has been enlightening and it looks like a good outcome.

 

 

Pauli

-- 

Oracle

Dr Paul Dale | Cryptographer | Network Security & Encryption 

Phone +61 7 3031 7217

Oracle Australia

 

From: Tim Hudson [mailto:tjh at cryptsoft.com] 
Sent: Monday, 16 April 2018 3:13 AM
To: openssl-project at openssl.org
Subject: Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

 

Where we are stating that ABI compatibility is in place we should be testing it.

i.e. the older release binaries should be run against the current release libraries - and that should be put into CI in my view.

 

Going the other direction isn't something I have thought we have ever guaranteed (i.e. downgrading) - but programs that don't use new APIs (i.e. for the ABI) should also work - that is pretty much the definition of an ABI.

If we are unable to provide the forward ABI then we need to change the version number of the release going forward. If weare unable to provide backwards ABI then we need to think about how we are defining things and make that clear.

 

And we need to be clear about what we mean by ABI - I don't think we have written down a clear definition - and then have in CI the tests to match what we are saying we do.

 

When it comes to TLSv1.3 it is highly desirable that an existing 1.1.0 application gets TLSv1.3 without API changes - i.e. ABI provides this. There will be some things where there are problems where assumptions are invalidated - but we should work to minimise those (and I think we have actually done so).

But again we should be testing this in CI - if we want old apps to all get TLSv1.3 for zero effort (other than a shared library upgrade) then we should test that in CI. Hoping it works or assuming it works and "manually" watching for changes that might invalidate that is rather error prone.

 

What Richard is doing really helps add to the information for informed decisions ... the more information we have the better in my view.

 

Tim.

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180415/ef8f2abb/attachment-0001.html>