[License Exception Request] [filepath-securejoin and libpathrs] [(MPL-2.0 AND BSD-3-Clause) and (MPL-2.0 OR LGPL-3.0-or-later)] #1154
Description
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 | containers/container-libs#359 kubernetes/kubernetes#131480 containerd/nerdctl#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 OR LGPL-3.0-or-later | 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). |
Are all of the components mandatory dependencies for the project to function as intended?
No
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 cyphar/filepath-securejoin#72.)
How will the components be included in or with the project's code and distributions?
- Incorporated code
- Vendored component
- Build-time dependency
- Build and test tooling
- 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.
Which of the following best describes how the components interact with the project's own code?
- Static linking: e.g., compiled together with project code into a single binary
- 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).
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