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.
Many things I run I want to limit to r/w a single dir, and to have to request permission to make network calls.
1. There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust.
2. Even if there were, if you’re compiling untrusted code then why would you trust the built output?
If you’re building the create then I’d argue that any preventative steps afterwards is akin to closing the barn door after the horse has already bolted.
Yeah, let's hold up the entire world of offensive cybersecurity capability while you work on that. Sure they will wait.
> 2. Even if there were, if you’re compiling untrusted code then why would you trust the built output?
You don't. You sandbox the hell out of it too.
Nice sarcasm but you’re not actually addressing a solution to the problem I raised.
> You don't. You sandbox the hell out of it too.
So you’re now saying it’s ok to have exploits compiled into your application as long as it’s sandboxed?
I wonder how customers of your application feel about that? I’m certainly not going to be entering my bank details into your ecommerce platform (to give just one obvious example why your suggestion wouldn’t work).
Arguing that compromised code is safer when sandboxed really misses the real problem: that you’re running compromised code in the first place. Hence my analogy of closing the barn door after the horse has already bolted.
What we need is to ensure we have stronger safeguards in place to prevent bad code from reaching build pipelines. If it’s in the build pipelines then we’ve already lost.
I get why people argue about sandboxing, it’s an easier problem to solve. But you still end up with a compromised artefact which you cannot ship. So the benefit is negligible.
Are you not concerned about an asteroid impact rendering you extinct during your next Rust build? Why not? That's the same level of relevance as your supposed concern.
> So you’re now saying it’s ok to have exploits compiled into your application as long as it’s sandboxed?
You need to act like it is compromised in all cases, just like everything else.
> I wonder how customers of your application feel about that? I’m certainly not going to be entering my bank details into your ecommerce platform (to give just one obvious example why your suggestion wouldn’t work).
So your version is "we trust everyone and don't verify anything". Yeah, that's going to work. By your "logic" firewalls wouldn't be necessary.
That’s a strawman argument and you’re still dodging the question.
> You need to act like it is compromised in all cases, just like everything else.
No. I act like compromised code is a legitimate risk regardless of how well your build pipeline is sandboxed.
I don’t understand why this is a hard concept for you to grasp.
> So your version is "we trust everyone and don't verify anything". Yeah, that's going to work. By your "logic" firewalls wouldn't be necessary.
That’s the literal opposite of my point (as well as another strawman).
Hmm . . .
> 1. There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust.
That is a straw man, right there, designed to attempt to ignore the substance of the original statements. Your hypocrisy is unbelievable.
Did you even read this thread? Or just assumed “anyone suggesting sandboxing wouldn’t work must be an idiot”? Because you’ve managed to misrepresent my comments at every opportunity.
No, you created two straw men and attacked them, then got upset at me pointing this out, while accusing me of doing exactly what you are doing.
> Or just assumed “anyone suggesting sandboxing wouldn’t work must be an idiot”?
Why, when we could assume malice instead?
> Because you’ve managed to misrepresent my comments at every opportunity.
Maybe it's your comments that are the problem.
I’m not upset at you. I’m just saying you’ve misread the thread and then proceeded to make invalid remarks because of that.
> Maybe it's your comments that are the problem.
I’ve managed to have a civil conversation on this topic with everyone else. Including the person you think I insulted (which I didn’t).
Once again you accuse me of exactly what you have been doing.
The other commenter calling your response "disingenuous" is putting it mildly.
Pity though, I would have been interested to talk to someone who was passionate about this topic.
This would be why I started the thread.
I said OS level. It's something I should easily be able to do via the OS capabilities that would work for rust, npm, etc.
I would use it not only for rust builds but for nearly every app on my computer.
Because we shall all trust the Cargo/pip/npm repository that nobody cares about ?
I wonder if this is not in part the same situation as we arguably had with the xz compromise: some imminent change would have made the attack harder (in xz's case, IIRC a change to systemd to dlopen the compression library instead of directly depending on it), and the attacker rushed before the opportunity window closed.
Granted some human will likely have to review it. Or packages flagged by Al could require users to explicitly allowlist them.