I don't directly disagree with what you're saying here either. All of these things need to be weighed against each other. I am not familiar with sudo's codebase, and so I can't speak to if I personally agree with Prossimo or you here.
What I will say is that I certainly agree that memory safety on its own would be a weaker justification for the reasons you cite. But this analysis doesn't take into account the relative usefulness of various language features for preventing logic errors. For example, I find that enums really help catch edge cases that are easy to forget about, causing bugs. Tagged unions are obviously a thing in C codebases but aren't as easy to use nor integrated into the language in useful ways, like exhaustiveness checking. You're absolutely right that, at the moment, the sudo codebase is more well understood, but one could make the argument that C's various weaknesses in areas like the typesystem means that as this codebase matures, and becomes well known itself, logic errors become more tractable.
One could also make an argument that a new codebase is a good idea, even disregarding the C vs Rust factors. For example, they're not going for "100% drop-in replacement for sudo," they're going for "a drop in replacement for common cases." Sudo has users who I assume would be upset at removing features they rely on, whereas this project has no userbase, and therefore, can do whatever they'd like. Removing a bunch of code can also help reduce logic errors, as it's impossible to have logic errors in code that doesn't exist, obviously. Of course, this article focuses on the memory safety aspects and not the others, maybe that's a marketing mis-step. Then again, what's important here is the engineering, not the marketing.
So yeah. It's not obviously a slam dunk either way, it really depends on how one personally weighs all sorts of factors. As I said above, time will tell.
While I appreciate Rust's correctness features and dearly miss `match` statements, as a software security professional with (I think I can say) a lot of experience looking for the kinds of vulnerabilities we're talking about here: I do not buy this theory of Rust's security advantage, like, at all. People have been saying things like this about strongly typed languages of varying sorts (Haskell was once a favorite) for over a decade, and it hasn't panned out. I think you'll find, if you look at the last (say) 10 meaningful sudo vulnerabilities, that there isn't a clear story about how enums would have steered you away from the problem.
Certainly, if there's an appetite for a reduced-fat version of sudo that caters to the 80-90% use case, I'm all for a Go, Rust, or whatever version of that thing. But then, C programmers were making the same argument 15 years ago, and nobody was able to sell the reduced-fat sudo (or, for the matter, the reduced-fat ssh, which we're all still dealing with). If it works out, great.
If it ends up gradually becoming a 1:1 equivalent to sudo, wartfeatures, and all, that's less great.
> I do not buy this theory of Rust's security advantage, like, at all.
Don't worry, you've made that overwhelmingly clear.
(I also know that I am not a security engineer, and respect your overall expertise here tremendously.)
> that there isn't a clear story about how enums would have steered you away from the problem.
Yeah man, I picked an example solely based on something that's done in both languages, but differently, because I thought it would be illustrative of the general idea. I am not claiming that enums will magically fix CVEs in sudo, that would be ridiculous. I'm saying "if we're saying memory safety is irrelevant, and logic errors are what matters, you should compare the tools that let you model your problem." Maybe Rust's features are truly irrelevant here, but as you say, I dearly miss match statements when I'm working in a language without them, so I suspect they do help in the general case of this argument, even if they don't for this one specific codebase.
> People have been saying things like this about strongly typed languages of varying sorts (Haskell was once a favorite) for over a decade, and it hasn't panned out.
I actually agree with this, but I don't think that the typesystem aspects are the cause here. Programming language adoption is weird, complex, organic, and really hard to see the future of. I think it's taken decades to "productize" more advanced type systems, and it's really only relatively recently (like, I'm not gonna try and pin down an exact moment, but like, let's say "the last ten years" but I suspect even that may not be far enough back) that we've seen larger adoption of this stuff. I don't even personally consider static typing to be strictly better than dynamic typing!
Oh and, if we're gonna nitpick examples, Haskell was never going to be a language to do that, one that expressly doesn't try to pursue popularity and broad usage. Those people (and I remember them too) were wrong then, and wrong now. But that's not (only) the fault of the type system.
That said, while I agree with the description of the history, I don't see how the trend points to this being impossible, but rather than we're now living in the time of truly being able to answer the question one way or the other. And the only way you do it is by putting in the work.
I'm aware that there is more to Rust than enums, and that you were using that as an example of a correctness feature that is part of a gestalt of correctness features. My point is that people have been arguing that more expressive languages with stronger type systems will be better able to model problems and thus avoid logic vulnerabilities, and that hasn't panned out at all.
Since I don't think there's any evidence to support your point that's a Google query away from you, I guess something you could present that would weaken my argument is an example of a recent meaningful sudo vulnerability where idiomatic Rust, written in the manner that a typical Rust programmer would use to solve the relevant problem, would have foreclosed on that vulnerability. Obviously: we pre-agree about memory corruption vulnerabilities here.
To be honest, on these issues, I'm not invested in winning an argument about it. I can see good arguments for why this would be beneficial, and I think they make sense. But I also know there's good arguments for why this would not be, and I can think they make sense too. I want to see both sides represented here, because I think it's interesting, and seeing both sides is good. That's good enough for me.
If in five years (or whatever) no distros use this new tool, it's had zero impact on things, I'll go "damn, tptacek was right," and that's an outcome I am totally fine with.
What I will say is that I certainly agree that memory safety on its own would be a weaker justification for the reasons you cite. But this analysis doesn't take into account the relative usefulness of various language features for preventing logic errors. For example, I find that enums really help catch edge cases that are easy to forget about, causing bugs. Tagged unions are obviously a thing in C codebases but aren't as easy to use nor integrated into the language in useful ways, like exhaustiveness checking. You're absolutely right that, at the moment, the sudo codebase is more well understood, but one could make the argument that C's various weaknesses in areas like the typesystem means that as this codebase matures, and becomes well known itself, logic errors become more tractable.
One could also make an argument that a new codebase is a good idea, even disregarding the C vs Rust factors. For example, they're not going for "100% drop-in replacement for sudo," they're going for "a drop in replacement for common cases." Sudo has users who I assume would be upset at removing features they rely on, whereas this project has no userbase, and therefore, can do whatever they'd like. Removing a bunch of code can also help reduce logic errors, as it's impossible to have logic errors in code that doesn't exist, obviously. Of course, this article focuses on the memory safety aspects and not the others, maybe that's a marketing mis-step. Then again, what's important here is the engineering, not the marketing.
So yeah. It's not obviously a slam dunk either way, it really depends on how one personally weighs all sorts of factors. As I said above, time will tell.