Whenever a complex system is rewritten, there are a lot of bugs and regressions in it.

Often worse than the original system, because the writers expertise and motivation are different.

At times the authors who rewrite-in-foo are just motivated to expand the foo ecosystem and are not primarily interested in making a working program, much less in possession of the requisite subject matter expertise or focus.

All the rewriters are offended by the truth.

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.

I’m a pretty big advocate on Rust and while Rust does protect classes of certain kinds of bugs and probably encourages better unit test hygiene and thus higher code quality, it does not protect against logic bugs and all the historical CVEs and thus it’s possible for previous exploits vectors to resurface. Thus it’s not an unreasonable prior to assume there are vulnerabilities lurking.

On the other hand, if the replacement isn’t targeting full sudo feature set and also reducing the amount of code and/or making architectural improvements like keeping most code not running as root, then the blast area of such logic bugs can be reduced.