[openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

[Matt Caswell]

On 27/01/17 16:54, Benjamin Kaduk via openssl-dev wrote:
> [moving from github to -dev]
> 
> On 01/27/2017 07:36 AM, mattcaswell wrote:
>>
>> 1.0.2 is the software version.
>> The numbers on the end of lbssl.so.1.0.0 refer to the ABI version -
>> which is different. Software version 1.0.2 is a drop in replacement
>> for 1.0.1, which is a drop in replacement for 1.0.0 - hence they all
>> have the same ABI version.
>>
>>
> 
> There was some discussion about 1.0.1 being EoL on a FreeBSD list [0],
> and whether it would make sense to move to 1.0.2 on their stable branch,
> which led to someone making the claim that 1.0.2 has removed 4 symbols
> compared to 1.0.1, and thus is not strictly ABI compatible, linking to
> https://abi-laboratory.pro/tracker/timeline/openssl/ .  If I start
> semi-randomly clicking around, I can find a page [1] that seems to claim
> the missing symbols are:
> ASN1_STRING_clear_free()
> ENGINE_load_rsax()
> SRP_user_pwd_free()
> SRP_VBASE_get1_by_user()
> 
> It may be too late to get the 1.0.x series fully compatible, but it's

Why can't we just add those symbols back in? I'm not sure why they were
removed...we should look at that, but if nothing else make them no-ops
or something. I'd look on it as a bug if there are missing symbols.

> probably worth thinking about how we can use automation to ensure that
> the 1.1.x series remains ABI compatible going forward.  I just learned
> about abi-laboratory.pro from the FreeBSD posting, so I don't know if it
> is appropriate or we would want to use some other tool.
> 

There is an abi build for 1.0.2 here already:

https://openssl-sanity.cisco.com:8443/job/1_0_2_abi/

Unfortunately John Foley left cisco so AFAIK this farm is no longer
being maintained...although it is still running.

Matt




> One (naive?) idea for a home-grown solution would be to come up with a
> scheme to serialize the public ABI to a file in the repo, maybe
> regenerated as part of 'make test', and ensure that that file is
> append-only, at least between releases.  But I don't know if the state
> of the art is more advanced than that -- are there better options?
> 
> -Ben
> 
> 
> [0]
> https://lists.freebsd.org/pipermail/freebsd-security/2017-January/009211.html
> [1]
> https://abi-laboratory.pro/tracker/compat_report/openssl/1.0.1u/1.0.2/c63bf/abi_compat_report.html#Removed
> 
>