3 ms·
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 t
by winstonewert 4y ago
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?
- mocko 4y agoIn 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.
- the_mitsuhiko 4y agoIf that build server runs tests too the surface area of such an attack is similar.
- ojkelly 4y agoA 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.
- yazzku 4y agoYou 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.
- winstonewert 4y agoAre you sandboxing your applications when you run them on your dev machine?