I don't have any special insight to this decision, but

> - 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.

You play to your audience. If someone decides not to use sudo-rs because it's in multiple packages, that may be a bad reason, but they're still not choosing it, and that's a worse world than if they did.

I would probably do the same thing, even though I am very much on the other side of this debate from the zero-dependency folks. The intended audience is probably much more full of folks who do believe that.

Agree the dependency count is mostly meaninglessly.

What matters is how many vaguely defined "entities" (people/groups/companies) you trust and how trustable each of them is.

Also there are not really zero dependency libraries, you always have some dependencies, e.g. the compiler implicitly is a dependency too. And so is your build system, and your languages standard library, and libc, etc. etc. So obsessing with "0" is like obsessing with "1.0" releases or abusing type systems, i.e. not helpful at all.

Additionally you can have "crate" dependencies, but you pin (or even vendor) them and give them a though "supply chain risk" review and them keep them pinned or require a another review. Sure you still have to keep track of stuff like bug fixed yanked versions etc. But for a lot of smaller crates it's feasible. In difference to some other languages it's quite easy to do so in rust (for many crates, for larger ones which have a lot of functionality where you might need bug fixes, maybe even for security this isn't that viable, but then in most projects there is only a very small number of such dependencies if any (e.g. tokio, rustls).

Agreed with everything you’ve pointed out. There seems to be an implicit assumption that all dependencies are bad, even though it’d actually be better to refactor their own code to a crate under their maintenance. Almost as if they think the people evaluating the security of this will apply a simple heuristic like “if number of deps is more than x, this software is insecure”.

Ya it feels funny projects that think dropping major packages like CLAP that have thousands of eyes on it, for a new hand rolled implementation is somehow ... safer/better by default.

Replacing and removing dependencies is great, if your really sure somehow your code is actually improving the situation and not just shifting the issue into a new chunk of code your going to have to worry about.

I'd like to respond to a few things. I think using dependency count as a metric is a bad idea, that metric could easily be lowered by just copying all the code over to your project. As you rightfully say, the logic has to exist one way or another. Our approach definitely wasn't that though: it was and is never our goal to have no dependencies, but we do think that dependencies should be part of the safety story, i.e. is a dependency better or worse than what you would write yourself based on your specific use case. This needle will fall much much quicker towards writing it yourself for something like sudo, but still, at least the considerations you make should stay the same, even if the decision ends up being different. Considerations such as: is the communication with the dependency team worth it for the amount of code we save, are their goals aligned with ours, is the number of transitive dependencies that I take within my codebase with this dependency small enough, how much code am I actually saving, would I even be able to do this myself, could I help the wider community with my contributing back to that dependency, etc. I do feel that right now more often than not dependencies are just bolted onto a project as needed, and no consideration is given to any burden such a dependency might have. Aside from that, I think at least a much better metric would be something like 'teams', 'groups' or 'projects' needed to keep your project working. Still not perfect, nor is any other metric, but sometimes it helps to quantify things.

Some responses to your notes:

- The trouble is that we had to re-implement an existing CLI, and as you might expect with something that evolved over a period of some 30 years, there are quite a few weird behaviors in sudo. We initially had a mostly working implementation based on clap, but could not get some parts of the CLI to parse nicely, i.e. the code just looked hacky, and had to do all kinds of post-processing to complete the parsing of the CLI, resulting in lots of additional code. Maybe we should have looked at something like lexopt, but we just went ahead and did it ourselves initially just to see how it would go, we kind of liked the result and never looked at any alternative implementations. I do believe we looked at clap alternatives for a little while to see if something would make our parsing a little easier, but lexopt didn't surface at that time for whatever reason. We're not perfect either. I do think our parsing is pretty decent though.

- We did think about contributing back, but in the end we wanted a little more control over where the password (or more precisely 'hidden input') was stored in memory, and needed some specific parts for handling TTYs (given our setuid context) resulting in us quickly deconstructing rpassword until almost nothing of it was left. I think it's a little hard to contribute those things back, but as a side project I'd love to contribute some of the changes we made back to rpassword, there just wasn't the time to do it at that time as it would be quite a bit of work.

- Glob is a hard one, as the Rust crate is not entirely compatible with how the original sudo works. But the logic has to be there one way or another and if we have to decide between libc (i.e. probably C code) and Rust, we'd prefer to go with Rust of course. That already resulted in an issue being opened for incompatibilities of course, but it's a hard one: I'd prefer to keep the Rust code, so I hope that someone who manages glob at least agrees that it should be as compatible as possible. But I can't and don't have the expectation that their team has the same priorities, and thus we are back at one of the reasons why a dependency might not always be worth it. There's always choices to be made. For now though, we'll keep the Rust crate dependency, as it works well enough!

- Thiserror is great for prototyping, but loses its value quickly once you know what kind of errors you have, it just takes a few lines of extra code. But, thinking about teams etc: given that it is not that big, and is created and maintained by dtolnay, whose code you probably already use in multiple ways in nearly any other project, it's not the worst either. For sudo-rs though, I still think it was the better choice to remove it.

- All the sudo-* packages were mostly removed because we didn't want to expose any public API for all that internal stuff. Our initial goal is to get sudo the CLI application working, not to provide all the building blocks while the API is still in flux. We initially put it all in separate crates because of compilation time worries, but in the end those worries were unfounded. It's one of those things where Rust is still somewhat limited: we can't specify these sort of semi-private dependencies in the crates ecosystem right now, if we would have been able to specify 'nobody but us can use these as a dependency' they would have probably stayed as separate crates.

BTW: I'd like to thank you for continuing to work on Clap! There might have been a time I would have been a little worried about all the breaking changes and churn happening, but since that has stabilized I couldn't be happier! I don't think there's anyone on the sudo-rs team that had anything against clap, and I did not want to single out clap in our post specifically, so I hope you don't consider it an attack against clap. At least personally I use clap in basically every other project with a CLI.

If the system-provided libc is corrupt, isn't sudo the least of your concern? What else is going to work?

What distros are there that normally dynamically link everything but statically link sudo? OpenSUSE, Debian and Ubuntu (the distros I have on hand) do not, at least.

Funnily enough something similar happened to me after doing a partial update. Doing a partial update are not supported in arch linux for this very reason.

sudo broke as well as many others command. ssh worked for a bit and then segfaulted. I edited my PATH to have a healthy version of libc but things kept breaking in different ways (version mismatches) In the end I had to use a live usb drive as I couldn't write to /usr/lib

This only works on Linux of course since the Linux kernel and libc are not tightly coupled, on any other OS dynamically linking against libc is a necessity. Also, I've never seen anyone statically linking against glibc? Is that even something people do? I'd consider your system provided libc being broken is a similar situation to an unbootable kernel: you just need a rescue stick/partition to fix it, or reinstall your OS.

I'd invest $10 into a rescue USB stick regardless. I like putting Ventoy on it and having a large number of different distribution ISOs on there, just in case.

I like this idea. Theoretically, the compiler already has the machinery to remove dead code. Next step could package up just the source you touch.

it's not trivial to do if you have multiple build targets and features

i.e. you would need to vendor one version for each features x target tripple combination combined with cfg expansion and (proc) macro expansion inlining and then a static reachability analysis to prune all unused code (and dependencies). That would likely not be good enough so you probably need to have some runtime code coverage analysis to find "likely dead code" (but not statically provable dead code) and then manual choices to keep/remove combined with some bisecting/testing to make sure the choices are sane.

Afik such tool doesn't exist.

And it's non trivial.

But it's also very viable to create it.

You can get that info from code coverage, via `cargo llvm-cov` etc, though that would require exercising all code paths into the deps or else you might underestimate how much of the deps you need to vendor. But at least if you underestimate in this way, you'll probably just get a compiler error rather than anything breaking at runtime.

> Our current target is to build a drop-in replacement for all common use cases of sudo.

In my understanding, the same general comparison as doas to good old regular Classic (tm) sudo. They're going for "basically the same thing, but with some stuff removed" rather than a re-think of the tool.

It's like harm reduction: the idea is to be able to replace sudo with a memory-safe version where sudo is already entrenched in a workflow, not to be a successor that's somehow better in a more abstract sense.

Don’t think it’s worth it. Looking at sudo’s man page at https://linux.die.net/man/8/sudo, it looks like sudo only uses single-letter flags, some of which take arguments. Argh implements long options, built-in parsing, subcommands, and lots of other nice to have features that nevertheless add a lot of code. It’s normal in traditional UNIX C programs to parse sudo-style flags in a handful of lines without any external dependencies.

I've used argh a fair bit. It has some weird ideas and restrictions and generally isn't nearly as good as clap. I would definitely recommend clap (unless you have extreme security concerns like this).

Why not use `getopt()` which already exists in libc?

(Or even `getopt_long()` if you're Linux/glibc-only? Author mentions not supporting Windows, but is unclear whether non-Linux Unices, e.g. *BSD, are intended target platforms.)

https://manpages.debian.org/bookworm/manpages-dev/getopt.3.e...

This also had a bigass HN discussion recently, for those interested https://news.ycombinator.com/item?id=39305452

> Our profession (like many, many others, if not all!) requires judgement to do the best job.

And is almost permanently open to retrospect + disagreement of "you shouldn't have done that this way and followed maxim A, you should've followed maxim B instead" and vice versa... :)

This sets up some bad incentives.

If someone decides part of a package is useful and extracts it out into another crate, then that will count as a demerit going by this rule, even though it should be rewarded.

But in this post we're seeing this "mindset" trickle to the Rust ecosystem, for something as "complicated" as command-line argument parsing

100% this, and I really hope we can turn the Rust culture ship around on this front.

I've been ranting about this a lot, and getting about a 50% upvote vs downvote ratio :-)