[openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2
Andrey Ponomarenko
andrewponomarenko at yandex.ru
Sun Feb 26 06:26:06 UTC 2017
31.01.2017, 10:21, "Nikos Mavrogiannopoulos":
> 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.
Hello,
These pages on OpenSSL wiki may be helpful:
https://wiki.openssl.org/index.php/Binary_Compatibility
https://wiki.openssl.org/index.php/ABI_Tracker
Thank you.
More information about the openssl-dev
mailing list