feat: verify libpathrs version at both compile time and runtime#5344
feat: verify libpathrs version at both compile time and runtime#5344lifubang wants to merge 2 commits into
Conversation
4f19545 to
f49d934
Compare
Signed-off-by: lifubang <lifubang@acmcoder.com>
Signed-off-by: lifubang <lifubang@acmcoder.com>
f49d934 to
84059ee
Compare
|
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 |
|
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
Happy to adjust based on your recommendation -- you're the expert on libpathrs stability. |
|
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. |
We currently lack a clear error message when the
libpathrsversion is insufficient.To address this, we should check the
libpathrsversion at both compile time and runtime.