Melange SCA for shared library dependencies should be versioned

[xnox]

$ docker run --rm -ti --entrypoint sh cgr.dev/chainguard/wolfi-base@sha256:d6b37317ae7cb5c0864189e9e5acd825386ae226a413e7c19370f5f87d150f92
/ # apk add openssl~3.0
fetch https://packages.wolfi.dev/os/x86_64/APKINDEX.tar.gz
(1/1) Installing openssl (3.0.7-r3)
WARNING: Support for packages with multiple data parts will be dropped in apk-tools 3.
OK: 16 MiB in 15 packages
/ # openssl version
OpenSSL 3.0.7 1 Nov 2022 (Library: OpenSSL 3.3.1 4 Jun 2024)
/ # apk add openssl~3.1
(1/2) Installing openssl-provider-legacy (3.4.0-r1)
(2/2) Upgrading openssl (3.0.7-r3 -> 3.1.4-r1)
OK: 16 MiB in 16 packages
/ # openssl version
OpenSSL 3.1.4 24 Oct 2023 (Library: OpenSSL 3.3.1 4 Jun 2024)
/ # apk add openssl~3.2
(1/1) Upgrading openssl (3.1.4-r1 -> 3.2.1-r0)
OK: 16 MiB in 16 packages
/ # openssl version
OpenSSL 3.2.1 30 Jan 2024 (Library: OpenSSL 3.3.1 4 Jun 2024)
/ # apk add openssl~3.3
(1/1) Upgrading openssl (3.2.1-r0 -> 3.3.2-r2)
OK: 16 MiB in 16 packages
/ # openssl version
OpenSSL 3.3.2 3 Sep 2024 (Library: OpenSSL 3.3.1 4 Jun 2024)
/ # apk add openssl~3.4
(1/1) Upgrading openssl (3.3.2-r2 -> 3.4.0-r1)
OK: 16 MiB in 16 packages
/ # openssl version
openssl: /usr/lib/libssl.so.3: version `OPENSSL_3.4.0' not found (required by openssl)
openssl: /usr/lib/libcrypto.so.3: version `OPENSSL_3.4.0' not found (required by openssl)
/ # apk add -u libcrypto3 libssl3
(1/2) Upgrading libcrypto3 (3.3.1-r4 -> 3.4.0-r1)
(2/2) Upgrading libssl3 (3.3.1-r4 -> 3.4.0-r1)
OK: 15 MiB in 16 packages
/ # openssl version
OpenSSL 3.4.0 22 Oct 2024 (Library: OpenSSL 3.4.0 22 Oct 2024)
/ # exit 0

Above show that libcrypo3 / libssl3 v3.3 are backwards compatible with openssl binaries versioned v3.3; v3.2; v3.1; v3.0.
However libcrypto3 / libssl3 v3.3 are not forwards compatible with openssl binary versioned v3.4.
Same is true for many other applications such as python wolfi-dev/os#33218 and really any other users of openssl.
Same is true for major upgrades of glibc; when applications start to use newer versioned glibc abis.

It would help a lot if libcrypto3 package had provides = so:libcrypto.so.3=3.3.1-r4, and for each of openssl~3.N packages had depends = so:libcrypto.so.3>=3.N as then openssl~3.4 would have not been a valid candidate to apk add, unless `libcrypto3 was upgraded from 3.3. to at least 3.4.

Other distributions resolve this by either not changing API/ABI ever (i.e. a given release of ubuntu/debian/rhel/fedora do not upgrade openssl, not an option for a rolling distribution like Wolfi) or by using symbol level versioning.

Symbol level versioning relies on a library package maintainer to maintain a full list of symbols; and when they were introduced; such that package build process can generate accurate versioned dependencies. OpenSSL symbols are well maintained https://salsa.debian.org/debian/openssl/-/blob/debian/unstable/debian/libssl3t64.symbols?ref_type=heads however other libraries can be more complicated. See forexample https://sources.debian.org/src/zlib/1%3A1.3.dfsg%2Breally1.3.1-1/debian/zlib-core.symbols/ where lots of symbols have matching versioned symbol as the minimum package versioned; many which do not have version assigned to a symbol; or where there is drift of what a given symbols is declared as versus what the minimum required version is. This is highly accurate and flexible, but requires by-hand analysis and maintainance.

A pragmatic middle ground could be to update all the so: provides to be versioned; and ensure all depends on so: to be in the from >=${{the provider package full version}}. meaning such that packages like openssl and python-3.12-base gain depend = so:libcrypto.so.3>=3.4.0-r2 and depend = so:libcrypto.so.3>=3.3.1-r2 and so on, depending on which version of libcrypto3 package was present in the build environment.

This is not unique to openssl; as the same is true for glibc, libgcc, and all other libraries with a history of multi-year stable ABI, backwards compatible, but not forwards compatible.

[xnox]

Landing #1622 first may make implementing this request easier.

[smoser]

I realized there is bit of a problem with this solution (I think) in the event that there are 2 packages that provide so:libfoo.so.1 that we probably at least need to think through.

if you build apk-tools witih zlib-ng-dev in it's environment, then it would get a dep on so:libz.so.1>=2.2.2 (zlib-ng's current version) but zlib is only going to provide so:libz.so.1 at 1.3.1 . That would mean zlib is insufficient simply because it's software version is lower than zlib-ng. That seems fine in this example, but zlib decided to start versioning with '2024.1' and still providing libz.so.1 then it would flip.

[hectorj2f]

@xnox @smoser Could you both share more details of what is missing from this feature request ?

[xnox]

@smoser if there is more than one provider of shared library, even today we must specify explicit dep on the runtime package name.

Like for example today we compile against udev, but use eudev at runtime which is wrong and almost works

This is sort of why dpkg provides shlib deps and resolves sonames to real package names at build time; rather than having virtual dependencies on so:

Generating better version deps will help for the majority cases of a single provider of the runtime library.

It is true that for multiple providers neither status quo, nor this proposal addresses resolution and we need something else (manual deps, or deps resolved to package name).