| ▲ | fidotron 3 hours ago |
| Doing 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. |
|
| ▲ | jonahx 2 hours ago | parent | next [-] |
| Proper and easy to use support for sandboxes at the OS level, or better yet capabilities, seems like the only long term solution. Many things I run I want to limit to r/w a single dir, and to have to request permission to make network calls. |
| |
| ▲ | hnlmorg 34 minutes ago | parent [-] | | Two problems with this: 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. | | |
| ▲ | fidotron 14 minutes ago | parent [-] | | > 1. There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust. 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. |
|
|
|
| ▲ | jfklgkdkdnn 2 hours ago | parent | prev [-] |
| minimum-release-age |
| |
