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.