From: Stuart Henderson Subject: Re: Investigating adding functionality to doas To: Aaron Rainbolt , Matthias Kilian , tech@openbsd.org, adrelanos@kicksecure.com Date: Fri, 29 Nov 2024 17:39:13 +0000 On 2024/11/29 09:44, Theo de Raadt wrote: > Stuart Henderson wrote: > > > An alternative would be to put the configuration sections for these > > various programs into a default doas.conf distributed with the system. > > Or use a special binary based on doas which is _just_ used for these > > "internal" elevations and permits only them. > > But the ship has sailed. I meant in a fork, that's clearly not possible in doas itself. > We are not going to make this more complicated, and affect the existing > users who rely upon the simplicity. > > It is simple for a reason. There are always people showing up and saying > "but I want it to be more complicated, and here are my complicated reasons, > and the people who rely upon simplicity will just adapt". ... > Anyone is free to fork doas codebase, add all the features they want, > CALL IT BY A NEW NAME WITH NEW COMMANDNAME, and in a couple years collect > all the features of sudo and start collecting bug dangerous reports in > those features. Anyone who thinks this isn't how it will play out is > being dishonest. yep. On 2024/11/29 11:30, Aaron Rainbolt wrote: > I am well aware that forking doas is an option. It's also one I'm > trying to avoid like the plague because as much as I trust I can write > good code, I don't trust myself to write good enough code on my own. > The fact that the only two CVEs ever reported against doas were both in > a fork of it and only affected the fork does not escape me, and that's > another big reason why I want to work with upstream rather than forging > my own path alone. Especially since this is an SUID-root utility. But doas relies on TIOCCHKVERAUTH (in the kernel) for persist, so you need some kind of fork anyway...