opencontainers / opencontainers/runc
Fail build if libseccomp below some minimum version?
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 13.5k
- Forks
- 2.3k
- Avg merge
- 2d 8h
- Merged PRs (30d)
- 30
Description
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
but this is not visible when doing make & make install.
Xref also #1016
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading script/seccomp.sh lines 8–13 and comparing that check with the default make and make install path. Trace how libseccomp is detected during the build, then review the discussion and cross-reference in #1016. Done means the project has an agreed default behavior for too-old libseccomp and the relevant build path reflects it.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- shell
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100