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/858c71f7-cf54-4c80-b019-9ca883db68ddn%40googlegroups.com.

Reply via email to