We need effect based languages now. It's the only way to guarantee policies like no network, no file access, no unsafe code or FFI for a library before it even compiles. If anyone from epic is reading this please give us a timeline for open sorucing the Verse compiler. In the mean time I think it's possible to hack Cargo and run all build scripts in a microVM. The blast radius will be limited to malicious code in the…
Malicious Rust crate Arrayref runs a build-time payload
161–170 of 527 posts
Re: Malicious Rust crate Arrayref runs a build-time payload
#162Earlier quoted context omitted.
> It's the only way to guarantee policies like no network, no file access, no unsafe code or FFI for a library before it even compiles. It's not the only way. You can sandbox processes. I think sandboxing is the much more reasonable approach, because in the end of the day, there are still closed-source software products where you can't demand that the manufacturers use certain language safety features.
Sandboxing the process only works well when the malware requires more capabilities than the software itself. So if your software needs to make HTTP requests and read the filesystem then the malware will be able to make HTTP requests and read the filesystem, which is enough for a ton of malware. Sure, maybe you can limit the directories it can access a bit and possibly some sort of network filtering, but it isn't a si…
Re: Malicious Rust crate Arrayref runs a build-time payload
#163Earlier quoted context omitted.
> The technology works fine if you use it in a disciplined way. Then obviously we have to discuss the implementation! > Or just invoking bwrap. Or sandbox-execute. There's no performance overhead. Complexity is minimal. Just read current Codex source code. It's not so bad. People have been making these sandbox tools for AI agents for years. Just need to apply sandboxing to all domains. Tools like bwrap literally coul…
Browsers have been sandboxing their tabs since 2008. Don't sit there and tell me that bwrap, sandboxing, whatever is some kind of recent innovation with uneven distro support. And yes, bwrap needs root or namespaces. So what? So does sudo. Setuid binaries are as old as time. You know what's also been around and doesn't require root? Landlock. Have you heard of it? Has anyone? There's a huge PR and visibility gap in t…
Yes, it's an amazing feat that has cost billions and led to major features like seccomp v2, ptrace sandboxing, etc. Do you know the history of browser sandboxing? It's pretty complex, a major technical feat.
> Don't sit there and tell me that bwrap, sandboxing, whatever is some kind of recent innovation with uneven distro support.
I can tell you that unprivileged sandboxing is not only new, it's ongoing and nascent work and not commonplace at all.
> And yes, bwrap needs root or namespaces. So what? So does sudo. Setuid binaries are as old as time.
These are massive footguns and issues for deploying code... You don't get that? Again, implementations have tradeoffs.
> You know what's also been around and doesn't require root? Landlock.
lol it is SO NEW what the fuck dude?
> Have you heard of it? Has anyone?
Yes, I use it!
> "Oh, the technology works, but it need setup! Oh, my distro doesn't enable it! Oh, it doesn't work out of the box with my code!"
> This is a social problem.
Yeah these sound like social problems if you have literally no idea what you're talking about lmfao. IT's BOTH.
Your ignorance is blatant and your position is dead in the water.
Re: Malicious Rust crate Arrayref runs a build-time payload
#164Rust suffers from the same faults as the JS ecosystem. Any significant crate imports hundreds if not thousands of dependencies. The probability that one of the authors gets targeted by AI-assisted attacks is just too high. Also most of these dependencies provide a breadth of features that the end package does probably not need.
Re: Malicious Rust crate Arrayref runs a build-time payload
#165Earlier quoted context omitted.
More than that, we need capability-based languages. No capability passed to it, no permission.
First we need capability-based OSes, like we should have had decades ago if worse-is-better hadn't stuck us with Unix. I don't need to care whether or not a program was written in a capability-aware language if the OS fundamentally takes care of that for me.
Re: Malicious Rust crate Arrayref runs a build-time payload
#166Doing software development outside of strict containerization, at the very least, looks increasingly prone to disaster. Yes, we can argue about the culture of package management (as some of us have with especially npm from day one), but it's done, and your colleagues or AI sidekicks cannot be trusted not to download whatever and try to build and run it. All you can do is limit the effective blast radius.
minimum-release-age
Re: Malicious Rust crate Arrayref runs a build-time payload
#167Earlier quoted context omitted.
This was actually the main thing that put me off of Rust. I get the argument for a small std lib. I just also don’t agree it’s worth it. Go seems to handle having a batteries included standard lib just fine.
On the other hand, there are some bad Go standard libraries that are frozen in time.
Re: Malicious Rust crate Arrayref runs a build-time payload
#168> arrayref is a small crate of four macros. Why do so many languages fall into this horrible practice?
Re: Malicious Rust crate Arrayref runs a build-time payload
#169I think we should be taking a more “batteries included” approach to language and library design. The entire reason we’re in this mess is because we’ve decided it’s ok or maybe even preferable if stdlibs are rail thin, rendering base languages near-unusable. I can very easily build a highly functional, pleasant to use Apple platform app with 5 or fewer top level dependencies. In many cases, I reach for between 0-2 tot…
The Odin programming language does this! It has also decided not to provide a package manager.
If Odin gets moderately successful someone will probably reinvent it.
Re: Malicious Rust crate Arrayref runs a build-time payload
#170Earlier quoted context omitted.
There was a recent talk which explored this question (Dependency Cultures, by Richard Feldman): https://www.youtube.com/watch?v=E82ly38YEEQ Summary: it's cultural. Rust likely inherited the practice from Nodejs, who inherited it from Ruby. I think in Rust online spaces in particular there is also this undercurrent of "you're not smart enough to use certain parts of the language, so download libraries that handle that…
i'd like to welcome you to the hell that is c/c++ dependency management. Make? cmake? qmake? conf? autoconf? configure? autotools? submodules??? AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA