On 2024/11/29 09:44, Theo de Raadt wrote:
> Stuart Henderson <stu@spacehopper.org> 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...