On Thu, Nov 28, 2024 at 07:06:02PM -0600, Aaron Rainbolt wrote:
> I've been playing with doas on Linux lately, since I work with a
> project (Kicksecure) that is interested in switching from sudo to doas.
> The much smaller size and secure upstream fits well with what we're
> trying to do. However, there are a few features missing from it that
> would be quite useful for our use case, which I'd be interested in
> contributing to OpenBSD if they aren't considered "too much":

I do not speak for the project, but I think the chances of having any
of the functionality you describe added to doas is minimal. The reason 
is quite straightforward: doas was specifically designed to be as simple
as possible while still being useful to the OpenBSD developers themselves.

The reason doas exists is that keeping the base sudo in sync with the ever
increasing complexity of the upstream code became a maintenance nightmare.

Unless you are at least a little involved in developing the system, chances
are (I estmate upwards of 90% of the active users) your needs will be covered
by simply copying the default /etc/examples/doas.conf to /etc/doas.conf and
be done with it. To save you the trouble of looking up the result, this
would leave you with a configuration that has this as the only active line:

permit keepenv :wheel

which again covers the practical needs for the vast majority of us.

Developers or active testers with a need to build packages from ports
or build the system from source may need some extra features, much as
described in the doas.conf man page. 

I can muster some sympathy for the desire to include the foot shooting
prevention features you describe, but to get any additional complexity
included you would need to supply extremely good code and present truly
convincing arguments that the desired results could not be achived in any
other way. The design goal for doas was to be as simple as at all possible
while remaining useful to the OepnBSD developers, so the bar for adding
functionality is high. Basically, you need to demonstrate that the added
complexity is worth the maintenance overhead in perpetutity.

That said, would perhaps your project needs be better served by using OpenBSD
going forward? ;)

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.