Skip to content

feat: verify libpathrs version at both compile time and runtime#5344

Open
lifubang wants to merge 2 commits into
opencontainers:mainfrom
lifubang:feat-libpathrs-min-ver
Open

feat: verify libpathrs version at both compile time and runtime#5344
lifubang wants to merge 2 commits into
opencontainers:mainfrom
lifubang:feat-libpathrs-min-ver

Conversation

@lifubang

Copy link
Copy Markdown
Member

We currently lack a clear error message when the libpathrs version is insufficient.
To address this, we should check the libpathrs version at both compile time and runtime.

lifubang added 2 commits June 25, 2026 10:41
Signed-off-by: lifubang <lifubang@acmcoder.com>
Signed-off-by: lifubang <lifubang@acmcoder.com>
@lifubang lifubang force-pushed the feat-libpathrs-min-ver branch from f49d934 to 84059ee Compare June 25, 2026 10:41
@cyphar

cyphar commented Jun 25, 2026

Copy link
Copy Markdown
Member

Do we have something like this for libseccomp?

libpathrs v0.2.5 did have breaking C ABI changes (which I did to "get it out of the way" before a proper release), but that is not something I plan to repeat.

Also we currently use the pathrs_version symbol which was only defined for v0.2.5 and thus you should not be able to compile nor run runc with a pre-v0.2.5 version already. Did you manage to run into this situation in practice, or is this meant as a preventative measure?

@lifubang

Copy link
Copy Markdown
Member Author

Hi @cyphar, Thanks for the quick review!You're right -- we don't have an equivalent runtime/build version check for libseccomp (we mostly rely on pkg-config + linker errors). libseccomp updates are relatively infrequent (the 2.5.x series lasted almost two years, with 2.6.0 released earlier this year), so the current approach has worked fine.For libpathrs the situation feels a bit different because the library is still relatively young. We are particularly concerned about cases where a patch release (e.g. 0.2.6 fixing a bug or security issue in 0.2.5) becomes available, but users or distro packagers stick with 0.2.5 since there is no clear enforcement or error message. The pathrs_version symbol already protects us from anything older than 0.2.5, but doesn't help with newer patch versions.This PR was mostly preventative + UX-focused: give users and packagers a clear, actionable error ("version X is too old, please upgrade to >= Y") instead of obscure link/runtime failures. Given that you don't plan further breaking ABI changes after 0.2.5, would you prefer we:

  1. Keep only the build-time pkg-config check (and drop the runtime one), or
  2. Simplify the implementation further, or
  3. Drop the whole thing if you feel the existing symbol + documentation is sufficient?

Happy to adjust based on your recommendation -- you're the expert on libpathrs stability.

@rata

rata commented Jun 26, 2026

Copy link
Copy Markdown
Member

My guess is that new features will be conditional to what is found at runtime and we won't require them. But I'd like to know what @cyphar thinks about this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants