When we install something via apt or pacman, etc, we have to use sudo for security reasons, because otherwise a hacker might be free to install malware. But this is not a problem for the hacker, because they can just run cargo install malware123 to install programs written in Rust that emulate the behavior of programs that can only be run in the sudo user, but these emulator programs installed via cargo install could be run in normal user (i.e. non-root). Thus the entire sudo protection get circumvented by the hacker using cargo install.
To fix this cybersecurity vulnerability, I propose that we make cargo install a sudo operation by default, so that the user has to type the sudo password to run this command.
This makes no sense, as cargo install installs per user. It is not a global install. In fact, running cargo install as root makes it less secure than as a normal user, since it would then have access to super user access when building packages.
You can use many many different ways to download and run programs as a normal user. Cargo install is not a security barrier. Just like npm or pip or wget aren't security barriers.
In conclusion I believe you have an incorrect mental model of computer security. What would actually improve security is installing and running software with reduced privileges (sandboxing).
To restate a bit, the reason Linux package managers require sudo is that they're installing software at the system level. What cargo install does is install at a user level and is closer to curl | sh installation. If a malicious actor has access to your user shell, they don't need a programming language to inject their payload, they just need curl | sh. And likely that's how they'll grab it, since that can work on a greater percentage of machines.
the only way to improve cybersecurity for cargo install specifically (and not builds in general, e.g. sandboxing) is probably either the usage of lockfiles or removing the subcommand permanently from cargo.
This is undesirable and, if backwards-compatibility is taken as seriously as generally is the case for Rust, not even feasible.
Take diesel as an example. Its CLI application is an integral part of using the library effectively (eg. to perform migrations) and so without a way to install that CLI app, diesel functionally breaks on stable. That is, you can add the library as a dependency to your rust crate, and it'll compile, but managing the backing database will be so onerous as to practically be useless. That's because it would then literally be easier to either use another programming language (and the same sql DB) or just use another DB altogether.
This is pretty pedantic so feel free to ignore it, but technically sh is a Turing-complete programming language. Just not one anyone would want to build anything significant in, for a long, long list of reasons
This is pretty pedantic so feel free to ignore it, but technically sh is a Turing-complete programming language. Just not one anyone would want to build anything significant in, for a long, long list of reasons
One thing that could help the security of cargo install is build sandboxing. Currently all that's necessary to pwn someone is to convince them to cargo install malware, because of build.rs and proc-macros. If those were sandboxed, it would require actually running the resulting binary to get pwned.
