[GOMODJAIL]: suggesting to replace indirect module syndtr/gocapability #4183
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See README for detailed rationale.
TL;DR:
This indirect dependency has an unavoidable
init()
routine that will systematicallyopenat
andfcntl
(reading/proc/sys/kernel/cap_last_cap
), even / while it is not necessary.gomodjail
will (righfully) block this, resulting in a series of loud warnings - or we would have tounconfine
this dependency.Precisely because this project has been abandoned for multiple years and the maintainer seem to have vanished, marking it unconfined feels exactly like the kind of things we should not do - as a likely candidate for a supply chain compromise.
This PR suggests we replace it.
The only part we do need is mundane (the mere list of linux capabilities), which is what we implement here from https://github.com/torvalds/linux/blob/master/include/uapi/linux/capability.h
Note that the state of this dependency has already raised concerns enough that most recent contributors have closed their PRs over there, and at least RH Kolyshkin did fork it: https://github.com/kolyshkin/capability
An alternative future / better solution would be for opencontainers/runtime-tools to address this on their side, since the dependency is getting pulled by them: