Yup, hence why the downvotes. :( I thought it was a no-brainer, but I guess not.

I see what you mean now. The way you phrased it came off as much more a critique of the language used and/or the developers using it, rather than the simple fact of it being a rewrite of a complex tool.

Also does `sudo` not have a spec or any existing unit tests for the previous vulnerabilities that they can benefit from? I'd be pretty shocked if there wasn't a lot of regression testing and documentation available to anyone implementing something this vital.

Rewrites by engineers can also uncover cases where the original tool does not conform to its own spec, this rewrite uncovered two issues with the original sudo.

One of our engineers involved in the project wrote about the testing approach they used and about the issues they found here https://ferrous-systems.com/blog/testing-sudo-rs/.

Later, a dedicated security audit for the rewrite was performes which uncovered three issues, one of which also affects the original sudo implementation. https://ferrous-systems.com/blog/sudo-rs-audit/

I generally support the notion that rewrites of large complex code bases are usually a bad choice, but sudo is not a particularly large codebase not is it particularly comples - it's just particularly sensitive. In those cases, I believe the tradeoff can fall the other way - rewriting old, feature-stable codebases (to a reduced scope) can lead to improvements on all axis.

Saying "a lot" and especially that it's still "a lot" is not a no-brainer.

Some. More than enough. Potentially two, critical ones. Is that better?

I bet you the existing program also has two critical bugs. It's replacing imperfect with imperfect and rewrites are not necessarily worse. Especially if a program grew a ton over time and you can give it a better structure and a better spec document.

There are systems where you really want to preserve accidental quirks of behavior that other things depend on. Sudo I think is not one of those.

Someone said this: https://news.ycombinator.com/item?id=44364842

I agree.

How about we just start using doas, anyway?

I'm not well versed in the motivation of this project.

But yeah a simpler program is probably good in this situation.