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

[Benjamin Kaduk]

[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
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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20170127/8ef92121/attachment.html>