In some point someone will rewrite all GNU/UNIX user land in modern Rust or similar and save the day. Until this happens these kind of incidents will happen yearly.
The problem is feature parity. Most rewrites cannot guarantee that off-the-bat, so they end up struggling to persuade people to switch - why break stuff that works just fine and lose features, in the name of some engineering purity?
https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/s...
Which also seems to not have tests. In fact, the only tests I'm seeing are from 2 years ago.
https://gitlab.freedesktop.org/polkit/polkit/-/tree/master/t...
> has much better security
It's using D-bus. My faith in D-bus security is close to my faith in seeing a fresh Linux install with zero D-bus error messages from apps. Which is to say, nonexistent.
> integrates with your DE instead of expecting passwords on the terminal.
There's nothing inherently insecure about passwords on the terminal, and certainly nothing a DE can do better. I have yet to see a display manager or lock screen app that knows what the hell PAM is doing. Try doing even the simplest things with PAM, such as getting a fingerprint reader or Yubikey working, and every single display manager simply chokes.
I'm not sure which is more of a Byzantine mess: Linux authentication and authorization, or Linux audio.
With all the .so modules loading into some process, etc. Some questionable design in sshd makes it lock up completely for all incoming connections when used with PAM and when pam module ends up in infinite loop.
Nevermind that systemd pam modules pull in a shitton of stuff, including dbus, into any process that tries to use PAM for auth, these days.
I guess it all runs as root, too. sshd at least tries to fork a child for all this and waits for it and kills it, so that the parent process can't be polluted. It just has no timeout when waiting for result, and doesn't accept further connections when waiting.
Sometimes it's better not to look too deep under the covers.
sshd needs to run as root (obviously) because it grants login shells to people, so it needs to run in a privileged context. And the PAM modules it executes also need to be run as root, because PAM modules need to do things like read /etc/shadow.
(In the past, OpenBSD had a login-locally-or-via-Kerberos binary there, which does show the downside of that approach over PAM's more flexible approach.)
Implementing a subset of sudo is a weekend project, for some values of useful.
openbsd dropped sudo for "weekend project" `doas`, in no small part because it does not support most of that stuff.
Here's the configuration file documentation: https://man.openbsd.org/doas.conf.5
Not that I have any faith in modern "best practices". I'm imagining `grep` written in modern a modern language like JS and I shutter when I think of the hundreds of micro-dependencies like "left-pad" that would need to be downloaded to make it work.
Maybe it's fair to say that systems programming languages are in a better state in terms of modern best practices than scripting languages.
You don't have to imagine: `ripgrep` exists and has all of 10 direct dependencies, 4 of which by the same author because they extracted features / systems from ripgrep (or developed them separately from the start) as they were useful on their own e.g.
* regex, for obvious reasons
* ignore to match and apply ignorefiles (gitignore and friends which ripgrep takes in account by default)
* bstr for conventional utf8 strings rather than guaranteed
* grep intends to be essentially "ripgrep as a library"
Or everyone just switches to musl + busybox.