Hacker News Reader

Comment by winstonewert | Hacker News Reader

So... if I'm using a third party crate, I'm already trusting it not to do bad things in my running application. Why is it such a big deal that it could do bad things during build time just before I run it? If I'm using a third party crate... I've got to trust it one way or the other. So what's the big deal here?

View on HN

In the context of a long-lived build server it could permanently compromise the machine, allowing an attacker to modify any other package you publish from there and maintain that access even after Rust has been fixed.

If that build server runs tests too the surface area of such an attack is similar.

A lot of things could also potentially compromise a long-lived build server, to the point where it’s better not to be long lived.

If it’s not practical to use a fresh machine/vm/container/function for each build, at least rotate them out more than once a day.

You need full repeatable control over the execution environment for hermetic builds.

I also agree rust needs to either fix mitigate this. One option you have is to disable networking on the build machine.

You can sandbox your application when it runs, but nobody's doing much about the dev environment. If you're working for a company and using VSCode, you are often just one malicious plugin update away from leaking the company's IP and/or having your system compromised. Similar case for Python packages and such Internet-facing code environments.

Are you sandboxing your applications when you run them on your dev machine?

Reply on news.ycombinator.com