For some more detail on the choices that went into this, see <a href="https://www.reddit.com/r/rust/comments/1b92j0k/sudors_dependencies_when_less_is_better/ktuf2t2/" rel="nofollow">https://www.reddit.com/r/rust/comments/1b92j0k/sudors_depend...</a><p>For myself, I think people focus too much on "dependency count" and not what those dependencies represent. For example<p>- If a subset of a package is pulled out, it is no longer a "zero dependency" package and some people look down on it.<p>- Whether you use a dependency or write your own, the logic has to exist. The main question is if there is a difference in priorities.<p>Applying those<p>- I really wonder about their claim that using clap took more code than doing it themselves. I also wonder about "not using many features" as there are a lot of usability features in clap that aren't items you check off on a list. If dropping clap, it should have been replaced with <a href="https://docs.rs/lexopt/" rel="nofollow">https://docs.rs/lexopt/</a> rather than rolling their own<p>- While rpassword had its problems, it would have been better to work upstream or create your own competition to upstream, rather than locking away the improvements within sudo-rs<p>- I think its the right choice to keep glob. So long as it implements the spec of interest, bringing it in doesn't buy you much while keeping it external gives you the whole "many eyes" situation<p>- I agree about dropping `thiserror`. It can be nice for prototyping or high churn code but if you write-and-forget your errors, you are carrying around that weight for nothing.<p>- Its unclear why they merged all of the sudo-* packages into sudo-rs. I wonder if those would have been cases where they benefit everyone for being split out for reuse.
I really think that they bury the lede:<p>> As a setuid program meant for elevating privileges, all code that is compiled into sudo-rs has the potential to accidentally (or intentionally) give access to system resources to people who should not have that access. The setuid context additionally puts some constraints on how code is executed, and dependencies might not have accounted for that context. We could not expect any of our dependencies to take into account such a context either.<p>This is the real problem. I've come to the conclusion that setuid programs basically shouldn't be using most libraries. The setuid environment is just fundamentally different. A normal library can have a debug output file who's location is controlled by an environment variable without that being a security risk. But the instant that program becomes setuid, that's an arbitrary file overwrite security bug. Most libraries aren't built with that in mind. They shouldn't have to be. Setuid is poorly designed.
If they don’t link libc statically it can become a problem if the system-installed libc is corrupt or incompatible. My Arch install broke once and I wasn’t able to run pacman to correct it, because the libc installed was not compatible with pacman. If sudo wouldn’t run, I would not even have a chance to repair the install without booting to live cd.
Is there any tooling which can tell you exactly which parts of a crate that you actually use and produce a minimized version for vendoring/auditing?
There is also cargo vendor (which turns dependencies into path dependencies).<p>Sometimes if you do security sensitive stuff it can be a good option to either:<p>1. pin dependencies and give each dependency a review for suspicious code<p>2. vendor them in some cases (e.g. applying patches, or if pinning seems to not be good enough for whatever reason likely related to offline building)<p>If you are not a very security sensitive project but still worry about the supply chain then it may also be an option to pin/vendor some dependencies but e.g. trust `tokio`, `regex` or similar.<p>E.g. not pin some more trusted dependencies but then pin some small utility crate from a random person which you don't want to write yourself and is trivial/self contained enough so that you likely might not care about any updates to it (still include it into security scans check why it was updated etc.).
How does this compare to OpenBSD doas[1][2]?<p>1. <a href="https://man.openbsd.org/doas" rel="nofollow">https://man.openbsd.org/doas</a><p>2. <a href="https://cvsweb.openbsd.org/src/usr.bin/doas/" rel="nofollow">https://cvsweb.openbsd.org/src/usr.bin/doas/</a>
> In the end, we chose the potential dangers of reimplementing command line parsing over the potential issues of including clap<p>Have you considered using argh ?
Seems like it has the upsides without the downsides.
> including crates for platforms such as Windows, which we obviously would not require as a Unix utility.<p>Probably a little less obvious now that Windows has their sudo?<p><a href="https://learn.microsoft.com/fr-fr/windows/sudo/" rel="nofollow">https://learn.microsoft.com/fr-fr/windows/sudo/</a>
> We replaced it with our own argument parsing once we noticed that adopting clap was taking more code than doing it ourselves.<p>I feel like it's obvious that there are two sides to this echoed throughout the "programming" community:<p>1. Don't pull a package in for what you can do yourself because it might have 500 dependenices for no good reason<p>2. Don't roll your own, use something off-the-shelf third-party that is actively maintained, open-source, well written/easily usable/fleshed out, etc.<p>They conflict...