On Fri, 29 Nov 2024 17:39:13 +0000
Stuart Henderson <stu@spacehopper.org> wrote:

> 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...

I mean, sure, but obviously the further one diverges from upstream, the
worse. Besides, I don't intend on using persist at all, partially
because Kicksecure doesn't need it, and partially because it's part of
what a fork would need to modify and that's scary.

Also, I should make a correction - I *thought* I checked the mailing
list archives for people making doas feature requests. Either the
archive glitched or I was tired when I did that, because now for some
reason I can find plenty of requests, where before I couldn't find even
one. Sorry about that.