I have no problem with doas on debian or arch through a package either.

Many sudo policies are often kind of horrible (even by default) and often facilitate privilege escalation, and then there was CVE-2019-14287 ( < 1.8.28 ) and CVE-2021-3156 ( < 1.9.5p2 ) which were plenty nasty. It's just way too huge for a setuid program, security tools shouldn't represent security holes as best as we can get away with it.

[1] https://www.thehacker.recipes/infra/privilege-escalation/uni...

precisely this.

Opendoas isn't immune to security problems, either, [1] but I try to have a policy of trying to use smaller programs and libraries of higher quality and sudo just isn't fitting the bill here. In production systems neither really needs to be installed/enabled (especially just to faciliate a local user to do whatever root can do), and su does just fine for administration tasks as long as you don't do something stupid like leave it logged in on tmux.

[1] https://nvd.nist.gov/vuln/detail/CVE-2019-15901

You might find this interesting: https://www.memorysafety.org/blog/sudo-first-stable-release/

Even better, add doas-sudo-shim to your system packages and disable sudo:

  security = {
    doas.enable = true;
    sudo.enable = false;
  };

  environment.systemPackages = [ pkgs.doas-sudo-shim ];