By the by, Sebastien, I notice Google's own Rust Cloud API (https://github.com/googleapis/google-cloud-rust ) uses build.rs, so it may be worth researching --
a) are they making a security mistake? b) is there something that mitigates this? c) why would they expect their customers to adopt poor security posture to access Google cloud, if it a risky behavior? d) maybe my initial read that it seems dangerous is off base? https://github.com/googleapis/google-cloud-rust *~/go/src/github.com/googleapis **$* *find . -name build.rs* ./google-cloud-rust/src/gax-internal/grpc-server/build.rs ./google-cloud-rust/src/gax-internal/build.rs ./google-cloud-rust/src/auth/build.rs *~/go/src/github.com/googleapis **$* On Thursday, October 30, 2025 at 7:40:21 PM UTC Jason E. Aten wrote: > To me, fundamentally, automatically "go getting" > something is massive security hole if that > process can execute arbitrary repo source code on my machine, right? > > Given that CGO_LDFLAGS_ALLOW has to be used to even get some > C projects to work, and given how paranoid (justifiably) Google and the Go > team are about avoiding security holes, I doubt having a Rust > dependency build automatically is a good idea; since that rust build > script can do just about anything. > > There is some interest in sandboxing cargo execution, I hear rumor, > but of course most sandboxes are not water tight. A 6 year old effort: > https://github.com/rust-secure-code/cargo-sandbox > > If the tradeoff really is that I have to run make, once, in my Rust > dependency, > that seems worth it. > > I built a little demo of that to show to myself that is possible. > https://github.com/glycerine/grusty > > Seems like a pretty small hurdle (running make/a Makefile/manually > executing the rust build script once), and pretty big > benefit for more security and less chance of being hacked, no? > > > On Thursday, October 30, 2025 at 2:28:41 PM UTC Sebastien Binet wrote: > >> hi Jason, >> >> On Thu Oct 30, 2025 at 08:31 CET, Jason E. Aten wrote: >> > Hi Sebastien, >> > >> > Given that Cargo is so much less secure than Go (no >> > equivalent of a module proxy), it might >> > be safer to let the Rust project be the "lead" or "top level" >> > project, and have the Rust build script; these >> > >> > https://doc.rust-lang.org/stable/cargo/reference/build-scripts.html >> > >> > pull in any Go dependencies. >> >> I considered this, mainly to have something like PyO3 but for Go (taking >> care of the minutiae of exchanging slices and stuff, generating header >> files for Cgo). >> but cbindgen does most of that already. >> >> however, using Rust's infrastructure as the driver won't allow for the >> resulting Go package to be easily "go get"-able nor easily import-able from >> client packages. >> (unless I've missed something) >> >> and that's the main issue/goal of this email plea. >> >> Perhaps the title of this discussion should be rewritten as: >> "how to wrap large libraries via Cgo and make these packages play nice >> with the pure-Go ecosystem ?" >> >> -s >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/1870f388-32df-4903-aa44-175ab3f1eb13n%40googlegroups.com.
