| > security issues popping up is still a common-ish problem? It seems to average out at a bit over 1 per year over the last 20 years, based on [1]; is that "a lot"? I guess? It's worth pointing out that while there certainly are memory-related C-style issues, quite a few are logic errors because all of this is rather subtle once you start adding features beyond what e.g. "doas" does. For example the recent "Sudoedit can edit arbitrary files"[2] is a somewhat subtle interaction between sudoedit, environment variables, and flag parsing. Previously there was [3] and [4] from 2004 and 2010. Will memory safety be a benefit? Of course it will. But I think these kind of issues are the real challenge here. A drop-in replacement for "sudo" is useful, but I have to wonder if it wouldn't be better to rethink the approach from first principles, taking 40 years of sudo lessons in to account. It's also surprisingly easy to shoot yourself in the foot with a wrong sudoers file, which is not strictly a security issue in sudo as such but also something that can probably be improved on? That 2023 sudoedit bug has been in sudo since 1.8, released in 2011, and Todd has been maintaining sudo since 1994, and he's actually pretty good as well as experienced with this kind of stuff. Yet he still missed it, as did everyone else, for well over ten years. It seems there are far more structural problems in the entire approach that go well beyond "C is not memory safe". That's certainly an issue, but in a way seems almost banal compared to the deeper issues. [1]: https://www.sudo.ws/security/advisories/ [2]: https://www.sudo.ws/security/advisories/sudoedit_any/ [3]: https://www.sudo.ws/security/advisories/sudoedit_escalate2/ [4]: https://www.sudo.ws/security/advisories/sudoedit/ |