cncf
[License Exception Request] [filepath-securejoin and libpathrs] [(MPL-2.0 AND BSD-3-Clause) and (MPL-2.0 OR LGPL-3.0-or-later)]
For which CNCF project are you requesting exceptions?
Blanket request for all of CNCF
Are you an official maintainer of this project?
No
List of components requiring an exception
| Component | Upstream URL | Project Usage URL | License(s) | Purpose |
|---|---|---|---|---|
| filepath-securejoin | https://github.com/cyphar/filepath-securejoin | https://github.com/containers/container-libs/pull/359 https://github.com/kubernetes/kubernetes/issues/131480 https://github.com/containerd/nerdctl/pull/4527 | MPL-2.0 AND BSD-3-Clause | Provide secure path resolution (and procfs) APIs on Linux. |
libpathrs and go-pathrs |
https://github.com/cyphar/libpathrs | MPL-2.0 (go-pathrs, pathrs python bindings)MPL-2.0 OR LGPL-3.0-or-later ( pathrs Rust crate, libpathrs.so) |
More fully-featured version of filepath-securejoin/pathrs-lite written in Rust. It can be used as a backend by pathrs-lite with the libpathrs build-tag (using the go-pathrs Go bindings in the same repo). It is also a Rust crate. |
Are all of the components mandatory dependencies for the project to function as intended?
~~No~~
As of the release of youki 0.5.7, pathrs is now a required dependency of a CNCF project and thus yes both projects are now mandatory dependencies for several CNCF projects.
If no, please explain
filepath-securejoin was fairly widely used by several CNCF projects (Kubernetes, containerd, Podman, buildah, cri-o) and is likely to be used by more projects in the future. As such I would like to request a blanket approval for all of CNCF, rather than the Kubernetes-only approval recently accepted in #1074. This is a mandatory dependency for several CNCF projects to function as intended.
libpathrs is an optional dependency of filepath-securejoin/pathrs-lite and provides more hardenings than the pure-Go version in filepath-securejoin. It can be enabled at build-time with the libpathrs Go build tag. (This was added in v0.6.0.) However, it is also used by youki as a Rust crate and is thus required for that use-case as well.
How will the components be included in or with the project's code and distributions?
- [ ] Incorporated code
- [x] Vendored component
- [x] Build-time dependency
- [ ] Build and test tooling
- [x] Install-time dependency
- [ ] Required upstream dependencies
- [ ] Other (please describe below)
If any of the above selections don't apply to all of the components listed in the table above, please explain
libpathrs can be used as a shared library (libpathrs.so) which would need to be available at installation time if the Go binary is not statically linked. The "vendored component" and "build-time dependency" fields apply to all components. For Rust projects like youki, pathrs is statically linked.
Which of the following best describes how the components interact with the project's own code?
- [x] Static linking: e.g., compiled together with project code into a single binary
- [x] Dynamic linking: e.g., compiled into a separate binary, running together with project code in a single address space at run-time
- [ ] Separate process: e.g., separate executable running in a different process space, interacting with project code only via mechanisms such as pipes, sockets, etc.
- [ ] Network interaction only: e.g., logically separated over a network and communicating only via mechanisms such as network API call, exchanging JSON data, etc.
- [ ] Other (please describe below)
If any of the above selections don't apply to all of the components listed in the table above, please explain
libpathrs can be used as a shared library and so binaries using it can use dynamic linking for the Rust portion. The "static linking" field applies to all components (as they are written in Go -- go-pathrs is Go bindings for libpathrs). For Rust projects like youki, pathrs is statically linked.
Will any of the components be modified?
No
If yes, please specify which components will be modified, and briefly describe the purpose and nature of the modifications.
No response
Will the project be seeking to contribute the modifications back to the upstream project?
None
Let me know if you'd prefer to have the libpathrs and filepath-securejoin requests be done separately.
Thanks for filling this @cyphar.
and some future CNCF projects like Podman/buildah
FYI, "Podman Container Tools" is a sandbox project containing Podman, Buildah and Skopeo so we are a CNCF project already, https://landscape.cncf.io/?item=runtime--container-runtime--podman-container-tools
Also I just remembered CRI-O uses it as well.
I don't know if there is a procedure to escalate this, but this is now blocking security updates for some CNCF projects, in particular the response to CVE-2025-52881.
For background, CVE-2025-52881 was fixed in the runc container runtime today with patches that use the new APIs available from filepath-securejoin. The OCI does not have any explicit license policy, and so the usage of filepath-securejoin posed no issue.
However, some CNCF projects either:
- Import the vulnerable code from runc directly (and thus need to be able to update). This is the bucket that buildah (and thus podman) find themselves in. They use the AppArmor code from runc directly and thus would need to update their runc dependency to fix the issue. Even if they decide to replace the usage of runc they would either need to reimplement large swathes of filepath-securejoin (possibly forking it) or try to write their own version. Neither of these would be practical solutions, especially compared to the much simpler solution of importing the working code (see https://github.com/containers/buildah/pull/6473 which is my PR to do just that).
- Other CNCF projects have very similar bugs that require very similar remediation. Youki had very similar bugs (see https://github.com/youki-dev/youki/security/advisories/GHSA-4g74-7cff-xcv8 and https://github.com/youki-dev/youki/security/advisories/GHSA-vf95-55w6-qmrf) and they fixed it by using the
pathrscrate (because it is the easiest way of solving these kinds of issues), despite it not being approved yet.
As the issues were under embargo, I couldn't discuss this openly earlier (though I sadly wasn't aware of the situation with buildah until yesterday, I was aware of the situation with youki earlier and I had hoped that #1074 was sufficient).
@jeefy @joannalee333 @krook
Any chance to prioritize this? This is blocker for upgrading opencontainers/selinux.
@AkihiroSuda There was an update two weeks ago in the CNCF Slack -- this was fast-tracked through the Legal Committee (thanks to @joannalee333) and has been sent to the GB for a vote. To quote the message (for those without a CNCF Slack account):
Hi all, I already knew this blanket request was coming, so I proactively asked the Legal Committee to vote on this at last week's meeting even though the issue hadn't been opened yet. Next step is to get the GB's approval by email. I'm expecting the GB will likely approve given they already approved an exception for this same dependency for Kubernetes. Because of KubeCon, the email approval might take take little longer than usual but should be done the week after KubeCon
The Governing Board (GB) has approved a blanket exception to allow any CNCF project to use filepath-securejoin under MPL-2.0 AND BSD-3-Clause as either (a) a vendored component, (b) build-time dependency, or (c) install-time dependency, in each case that it is dynamically or statically linked with the project’s own code.
The Legal Committee (LC) and GB were able to review and approve the filepath-securejoin exception fairly quickly, because they recently approved an exception for this same component for the Kubernetes project, and thus were already familiar with this component and its license change (see #1074).
This issue wasn't opened until after the agenda was set for the most recent LC meeting, and thus libpathrs and go-pathrs were not reviewed by the LC and were not included in the recent GB approval of the blanket exception for filepath-securejoin. However, libpathrs and go-paths will be queued for review by the LC at its next meeting, which hasn't been scheduled yet but will likely be mid-December or early January.
