Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
chore(deps): update module github.com/cyphar/filepath-securejoin to v…
…0.3.6 (#6066) This PR contains the following updates: | Package | Change | Age | Adoption | Passing | Confidence | |---|---|---|---|---|---| | [github.com/cyphar/filepath-securejoin](https://redirect.github.com/cyphar/filepath-securejoin) | `v0.2.4` -> `v0.3.6` | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | --- > [!WARNING] > Some dependencies could not be looked up. Check the Dependency Dashboard for more information. --- ### Release Notes <details> <summary>cyphar/filepath-securejoin (github.com/cyphar/filepath-securejoin)</summary> ### [`v0.3.6`](https://redirect.github.com/cyphar/filepath-securejoin/releases/tag/v0.3.6) [Compare Source](https://redirect.github.com/cyphar/filepath-securejoin/compare/v0.3.5...v0.3.6) This release lowers the minimum Go version to Go 1.18 as well as some library dependencies, in order to make it easier for folks that need to backport patches using the new filepath-securejoin API onto branches that are stuck using old Go compilers. For users using Go >= 1.21, this release contains no functional changes. - The minimum Go version requirement for `filepath-securejoin` is now Go 1.18 (we use generics internally). For reference, `filepath-securejoin@v0.3.0` somewhat-arbitrarily bumped the Go version requirement to 1.21. While we did make some use of Go 1.21 stdlib features (and in principle Go versions <= 1.21 are no longer even supported by upstream anymore), some downstreams have complained that the version bump has meant that they have to do workarounds when backporting fixes that use the new `filepath-securejoin` API onto old branches. This is not an ideal situation, but since using this library is probably better for most downstreams than a hand-rolled workaround, we now have compatibility shims that allow us to build on older Go versions. - Lower minimum version requirement for `golang.org/x/sys` to `v0.18.0` (we need the wrappers for `fsconfig(2)`), which should also make backporting patches to older branches easier. Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> ### [`v0.3.5`](https://redirect.github.com/cyphar/filepath-securejoin/releases/tag/v0.3.5) [Compare Source](https://redirect.github.com/cyphar/filepath-securejoin/compare/v0.3.4...v0.3.5) This release primarily includes a fix for an issue involving two programs racing to MkdirAll the same directory, which caused a regression with BuildKit. - `MkdirAll` will now no longer return an `EEXIST` error if two racing processes are creating the same directory. We will still verify that the path is a directory, but this will avoid spurious errors when multiple threads or programs are trying to `MkdirAll` the same path. [opencontainers/runc#4543](https://redirect.github.com/opencontainers/runc/issues/4543) Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> ### [`v0.3.4`](https://redirect.github.com/cyphar/filepath-securejoin/releases/tag/v0.3.4) [Compare Source](https://redirect.github.com/cyphar/filepath-securejoin/compare/v0.3.3...v0.3.4) This release primarily includes a fix that blocked using filepath-securejoin in Kubernetes. - Previously, some testing mocks we had resulted in us doing `import "testing"` in non-`_test.go` code, which made some downstreams like Kubernetes unhappy. This has been fixed. ([#​32](https://redirect.github.com/cyphar/filepath-securejoin/issues/32)) Thanks to all of the contributors who made this release possible: - Aleksa Sarai <cyphar@cyphar.com> - Stephen Kitt <skitt@redhat.com> Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> ### [`v0.3.3`](https://redirect.github.com/cyphar/filepath-securejoin/releases/tag/v0.3.3) [Compare Source](https://redirect.github.com/cyphar/filepath-securejoin/compare/v0.3.2...v0.3.3) This release primarily includes fixes for spurious errors we hit when checking that directories created by MkdirAll "look right". Upon further consideration, these checks were fundamentally buggy and didn't offer any practical protection anyway. - The mode and owner verification logic in `MkdirAll` has been removed. This was originally intended to protect against some theoretical attacks but upon further consideration these protections don't actually buy us anything and they were causing spurious errors with more complicated filesystem setups. - The "is the created directory empty" logic in `MkdirAll` has also been removed. This was not causing us issues yet, but some pseudofilesystems (such as `cgroup`) create non-empty directories and so this logic would've been wrong for such cases. Thanks to all of the contributors who made this release possible: - Aleksa Sarai <cyphar@cyphar.com> - Kir Kolyshkin <kolyshkin@gmail.com> Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> ### [`v0.3.2`](https://redirect.github.com/cyphar/filepath-securejoin/releases/tag/v0.3.2) [Compare Source](https://redirect.github.com/cyphar/filepath-securejoin/compare/v0.3.1...v0.3.2) This release includes a few fixes for MkdirAll when dealing with S_ISUID and S_ISGID, to solve a regression runc hit when switching to MkdirAll. - Passing the S_ISUID or S_ISGID modes to MkdirAllInRoot will now return an explicit error saying that those bits are ignored by mkdirat(2). In the past a different error was returned, but since the silent ignoring behaviour is codified in the man pages a more explicit error seems apt. While silently ignoring these bits would be the most compatible option, it could lead to users thinking their code sets these bits when it doesn't. Programs that need to deal with compatibility can mask the bits themselves. ([#​23](https://redirect.github.com/cyphar/filepath-securejoin/issues/23), [#​25](https://redirect.github.com/cyphar/filepath-securejoin/issues/25)) - If a directory has S_ISGID set, then all child directories will have S_ISGID set when created and a different gid will be used for any inode created under the directory. Previously, the "expected owner and mode" validation in securejoin.MkdirAll did not correctly handle this. We now correctly handle this case. ([#​24](https://redirect.github.com/cyphar/filepath-securejoin/issues/24), [#​25](https://redirect.github.com/cyphar/filepath-securejoin/issues/25)) Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> ### [`v0.3.1`](https://redirect.github.com/cyphar/filepath-securejoin/releases/tag/v0.3.1) [Compare Source](https://redirect.github.com/cyphar/filepath-securejoin/compare/v0.3.0...v0.3.1) - By allowing `Open(at)InRoot` to opt-out of the extra work done by `MkdirAll` to do the necessary "partial lookups", `Open(at)InRoot` now does less work for both implementations (resulting in a many-fold decrease in the number of operations for `openat2`, and a modest improvement for non-`openat2`) and is far more guaranteed to match the correct `openat2(RESOLVE_IN_ROOT)` behaviour. - We now use `readlinkat(fd, "")` where possible. For `Open(at)InRoot` this effectively just means that we no longer risk getting spurious errors during rename races. However, for our hardened procfs handler, this in theory should prevent mount attacks from tricking us when doing magic-link readlinks (even when using the unsafe host `/proc` handle). Unfortunately `Reopen` is still potentially vulnerable to those kinds of somewhat-esoteric attacks. Technically this [will only work on post-2.6.39 kernels][linux-readlinkat-emptypath] but it seems incredibly unlikely anyone is using `filepath-securejoin` on a pre-2011 kernel. - Several improvements were made to the errors returned by `Open(at)InRoot` and `MkdirAll` when dealing with invalid paths under the emulated (ie. non-`openat2`) implementation. Previously, some paths would return the wrong error (`ENOENT` when the last component was a non-directory), and other paths would be returned as though they were acceptable (trailing-slash components after a non-directory would be ignored by `Open(at)InRoot`). These changes were done to match `openat2`'s behaviour and purely is a consistency fix (most users are going to be using `openat2` anyway). [linux-readlinkat-emptypath]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=65cfc6722361570bfe255698d9cd4dccaf47570d Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> ### [`v0.3.0`](https://redirect.github.com/cyphar/filepath-securejoin/releases/tag/v0.3.0) [Compare Source](https://redirect.github.com/cyphar/filepath-securejoin/compare/v0.2.5...v0.3.0) This release contains no changes to SecureJoin. However, it does introduce a new `*os.File`-based API which is much safer to use for most usecases. These are adapted from [libpathrs][1] and are the bare minimum to be able to operate more safely on an untrusted rootfs where an attacker has write access (something that SecureJoin cannot protect against). The new APIs are: - OpenInRoot, which resolves a path inside a rootfs and returns an `*os.File` handle to the path. Note that the file handle returned by OpenInRoot is an O_PATH handle, which cannot be used for reading or writing (as well as some other operations -- [see open(2) for more details](https://www.man7.org/linux/man-pages/man2/open.2.html)). - Reopen, which takes an O_PATH file handle and safely re-opens it to "upgrade" it to a regular handle. - MkdirAll, which is a safe implementation of os.MkdirAll that can be used to create directory trees inside a rootfs. As these are new APIs, it is possible they may change in the future. However, they should be safe to start migrating to as we have extensive tests ensuring they behave correctly and are safe against various races and other attacks. [1]: https://redirect.github.com/openSUSE/libpathrs Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> ### [`v0.2.5`](https://redirect.github.com/cyphar/filepath-securejoin/releases/tag/v0.2.5) [Compare Source](https://redirect.github.com/cyphar/filepath-securejoin/compare/v0.2.4...v0.2.5) This release makes some minor improvements to SecureJoin: - Some changes were made to how lexical components are handled during resolution. There is no change in behaviour, and both implementations are safe, however the newer implementation is much easier to reason about. - The error returned when a symlink loop has been detected will now reference the correct path. [#​10](https://redirect.github.com/cyphar/filepath-securejoin/issues/10) Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/open-telemetry/opentelemetry-go). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS42OS4zIiwidXBkYXRlZEluVmVyIjoiMzkuNjkuMyIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiU2tpcCBDaGFuZ2Vsb2ciLCJkZXBlbmRlbmNpZXMiXX0=--> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
- Loading branch information
1 parent
c931cef
commit f8d12fc