On Fri, Nov 29, 2024 at 11:44:30AM -0600, Aaron Rainbolt wrote:
> 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.

The ship had sailed when the PAM code was added. OpenBSD doas doesn't
have that either, which is already a pretty big divergence.

-Bryan.