Aleksa Sarai

(2) would work the same way by default though -- you would be able to opt-in to it with a build tag at build time, but the default would still...

@rata > Both things are maintained in parallel, but how are both integrated into runc? That part I didn't get. So, the original model I had for migration was that...

My main gripe with (3) is that it would be quite strange for you to do `import "github.com/cyphar/libpathrs/go-pathrs"` and not actually use the same `libpathrs` implementation as every other language...

@lorenz I agree that embedding Rust in this way is less than ideal (and IMHO I find most of the FFI support in Rust to be kind of half-baked compared...

#70 makes it much easier for us to switch with a build-tag -- now we only need to wrap a handful of functions and add `go:build` tags to the top-level...

@leoluk My current plan is to make this an optional dependency you would opt-into with a `libpathrs` build tag. If you don't do this (i.e., you build things normally), you...

https://github.com/cyphar/filepath-securejoin/pull/72 implements option 2 (at build-time you can opt-into libpathrs support with `-tags libpathrs`).

I think that having it separate would better express that SemVer only applies to our specifications, not the Go bindings. However, I'm not quite sure how just having a separate...

Yeah, this is because we currently use a forked version of https://github.com/vbatts/go-mtree because we're waiting for these PRs to merged and a new release to be created: * https://github.com/vbatts/go-mtree/pull/211 *...

FWIW, I've added a comment to `go.mod` about the reason for the directive in 13c7ab54c4f67e172a71375f69197d5ce7f950d6.