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

Nikos Mavrogiannopoulos nmav at redhat.com
Tue Jan 31 07:20:32 UTC 2017


On Fri, 2017-01-27 at 10:54 -0600, 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()
> 
> 
...
> 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?

The abi-dumper and abi-compliance-checker tools can be used for that
purpose. In fact they are the back-end tools used by the abi-laboratory 
you quote above.

regards,
Nikos



More information about the openssl-dev mailing list