provide version with github.com/cyphar/filepath-securejoin v0.5

[Luap99]

The update in #237 bumped github.com/cyphar/filepath-securejoin to v0.6.0 but that version contains breaking changes as the top level MkdirAll, MkdirAllHandle, OpenInRoot, OpenatInRoot and
Reopen function were removed.

In practise this causes a big problem update wise since in order to fix the CVE we cannot just bump to github.com/opencontainers/selinux v1.13.0 as that triggers the transitive update of filepath-securejoin.
This means we cannot update in podman and buildah directly because we have at least one other library using these symbols, namely https://github.com/containers/storage who was recently moved into a monorepo which now uses the module path go.podman.io/storage.
Since storage is a critical library to podman we cannot just bump the latest version and update to that in podman, buildah either. We would need to version lock that with the corresponding still supported podman/buildah versions meaning a ton of backporting and release churn work for AFAICT no real gain.

The runc CVE fix was released with github.com/cyphar/filepath-securejoin 0.5.0 so I assume that has already sufficient protection? @cyphar can you confirm this? Using 0.5.1 here would also work.

If a downgrade on main is not possible or wanted would it be possible to branch, downgrade there and then maybe release as 1.12.1 here instead? That will not cause problems for people already on 1.13.0 as they would not get this as an update then.

[cyphar]

Switching to v0.5.1 would be fine, v0.6 just happened to be what go get pulled when I made the PR.

(It would be nice to have as many downstreams using v0.6 because it allows for easier libpathrs migration, but that's not really needed for older maintenance branches.)

Note that I also don't plan to backport stuff to a hypothetical filepath-securejoin v0.5.2, so future fixes (I'm working on one to resolve a seccomp-related issue we just found in runc) might end up requiring more backporting effort for you guys (sorry... 🥲).

[Luap99]

(It would be nice to have as many downstreams using v0.6 because it allows for easier libpathrs migration, but that's not really needed for older maintenance branches.)

Yeah that is fine and we did update main of course with the latest 0.6.0 release containers/container-libs#448

(It would be nice to have as many downstreams using v0.6 because it allows for easier libpathrs migration, but that's not really needed for older maintenance branches.)
Note that I also don't plan to backport stuff to a hypothetical filepath-securejoin v0.5.2, so future fixes (I'm working on one to resolve a seccomp-related issue we just found in runc) might end up requiring more backporting effort for you guys (sorry... 🥲).

Fair enough, I think the direction you are heading with libpathrs is nice because when we start using the dynamic library security fixes there would be contained to it and we would not need to update/vendor in every go consumer to rebuild them. Of course that doesn't solve the issue if the problem is on the caller side in the go code.

[cyphar]

https://github.com/opencontainers/selinux/releases/tag/v1.13.1