opencontainers / opencontainers/runc

Fail build if libseccomp below some minimum version?

Open
#5,002 4 comments 0 reactions 0 assignees View on GitHub

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

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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.