opencontainers
Fail build if libseccomp below some minimum version?
I'm well-aware of the warning text in the release notes
However we strongly suggest that you make use of your distribution's packages or download them from the authoritative upstream sources, especially since these libraries are related to the security of your containers.
Today I was looking at versions of libseccomp in various distros, and surprised/shocked to find that the newest versions of still-supported major releases like Alma 8.10/9.6 are on libsseccomp v2.5.2 which was released in Sept. 2021, 4 years ago.
Distros vs. libseccomp version
Some more (see here), compared with libseccomp tags. Distro EOLs are taken from here.
| Distro | EOL | libseccomp version | Release Date |
|---|---|---|---|
| Alma 8.10 | Mar. 2029 | 2.5.2 | Sept. 2021 |
| Alma 9.6 | May 2032 | 2.5.2 | Sept. 2021 |
| Alma 10.0 | May 2035 | 2.5.3 | Nov. 2021 |
| AmazonLinux 2 | June 2026 | 2.4.1 | Apr. 2019 |
| AmazonLinux 2023 | Mar. 2028 | 2.5.3 | Nov. 2021 |
| Debian 11 (Bullseye) | Aug. 2026 | 2.5.1 | Nov. 2020 |
| Debian 12 (Bookworm) | June 2028 | 2.5.4 | Apr. 2022 |
| Debian 13 (Trixie) | June 2030 | 2.6.0 ✅ | Jan. 2025 |
| openSUSE Leap 15.6 | Apr. 2026 | 2.5.3 | Nov. 2021 |
| openSUSE Leap 16.0 | Oct. 2027 | 2.6.0 ✅ | Jan. 2025 |
| RHEL 8.10 | May 2029 | 2.5.3 | Nov. 2021 |
| RHEL 9.6 | May 2032 | 2.5.3 | Nov. 2021 |
| RHEL 10.0 | May 2035 | 2.5.6 ✅ | Jan. 2025 |
| Ubuntu 22.04 (Jammy) | Apr. 2027 | 2.5.2 | Sept. 2021 |
| Ubuntu 24.04 (Noble) | Apr. 2029 | 2.5.5 | Dec. 2023 |
| Ubuntu 25.04 (Questing) | Jan. 2026 | 2.6.0 ✅ | Jan. 2025 |
So in many ways, relying on distro builds might not actually be such a good idea, even if they've been built by reputable sources? My question boils down to whether runc should fail to build (by default) if it finds a too-old libseccomp.
I see that the release scripts already contain a check
https://github.com/opencontainers/runc/blob/996278a1898690547c2546fdf6d2f2259b3eab8c/script/seccomp.sh#L8-L13
but this is not visible when doing make & make install.
Xref also #1016
runc does work with older libseccomp versions (usage of new features is gated via API version checks), though I don't think we have tests for that. I think requiring a very new version is not really necessary -- the primary thing you get in new versions is new syscall definitions, but if the kernel version is not being updated in LTS distros then those updates aren't really relevant. (And just looking at version information in distro packages is not the whole picture because LTS distros tend to prefer backports over updates anyway. A better metric would be when the latest package update was on each distro, and how often the packages get updates.)
The main reason I wrote that in our release notes is because users should opt to use the most appropriate libseccomp version (this might be the newest, but it might be whatever is supported by their distro if they have an enterprise license). We only provide the one used to build our binaries because it is necessary to comply the LGPL licensing requirements -- it is not meant to be an indication that the we prefer a particular version. I would also generally recommend dynamic linking against the system libraries because then system updates to libseccomp will apply to your runc binary too.
Thanks for the response
I would also generally recommend dynamic linking against the system libraries because then system updates to libseccomp will apply to your runc binary too.
Why would that be bad (aside if it's an ABI break)? If libseccomp fixes a bug and it gets deployed on a system where runc is linked dynamically against libseccomp, what would (likely) go wrong according to you?
Ah, I was trying to say you should do it for precisely that reason, but I think the wording makes it seem a little confusing ("dynamic linking against" should probably be "dynamic linking with", for whatever reason I seem to prefer saying it the former way).
"I would generally recommend dynamic linking against libfoo" versus "I would generally recommend against dynamic linking (with) libfoo". 😉
"I would generally recommend dynamic linking against libfoo" versus "I would generally recommend against dynamic linking (with) libfoo". 😉
Yeah, sorry, I fell into that trap 😅