doas 6.3p4: unreliable, antagonistic upstream with a bad security record

[eli-schwartz (Eli Schwartz)]

In the wake of sudo CVE-2021-3156, various packaging groups took an interest in the different options for command authentication. A popular one being referenced is OpenBSD doas: ​https://flak.tedunangst.com/post/doas

Which, regrettably, only works on OpenBSD. On the other hand, it's been ported to work elsewhere. There are two ports I'd like to point out:

• ​https://github.com/slicer69/doas/ (recently packaged in macports) (​repology link)
• ​https://github.com/Duncaen/OpenDoas/ (​repology link)

I raised concerns about the use of the former with @danchr and was encouraged to open a trac ticket.

For the record, I mostly packaged doas on a whim, after reproducing the recent security vulnerability with /usr/bin/sudo as included in macOS

Which is an eminently reasonable desire, alternatives are interesting. And the former is also being linked around quite a bit on reddit by the slicer69/doas author, so it's possible it seemed like a good first pick to investigate packaging. Unfortunately, it's actually a very bad pick.

• Consider this article by the opendoas author: ​https://π.duncano.de/slicer69-doas.html
• Consider my forum post when an Arch Linux user inquired into the difference between the two implementations: ​https://bbs.archlinux.org/viewtopic.php?pid=1953144#p1953144
• Consider this PR, and ask why the former version of the script ever existed -- terrifying, really (TOCTOU check if file in /tmp/, if not then cp it there for editing): ​https://github.com/slicer69/doas/pull/46

Salient points:

• slicer69 is based on an old OpenBSD codebase, opendoas is regularly synced
• slicer69 makes very elementary coding mistakes with serious security ramifications
• slicer69 denies problems, eventually commits fixes with highly misleading commit titles referencing minor, unrelated administrivia checked in at the same time
• slicer69 deleted github comments criticizing code as bad for security, then claims elsewhere that the comments were "harassment" and "being nasty". duncaen mentioned another issue on Twitter -- that cannot be deleted as easily, so slicer69 blocked the twitter account and committed another fix with misleading commit title

If you look at the repology versions,

• opendoas has been packaged on Alpine, Arch, Gentoo, Nix, Void...
• doas was packaged in pkgsrc, until a pkgsrc developer got concerned about that vidoas script, prevented it from being installed in pkgsrc, and introduced opendoas as an additional port alongside the doas one. A couple other groups recently packaged it in the last few days, and should likewise rethink

tl;dr I have grave concerns about the slicer69 port, and recommend the (older) opendoas one, which is used in many more places, and as I've crossed paths with Duncaen before -- he is a core developer for Void Linux -- I feel confident he's trustworthy, and he definitively comes across as more interested in security, safety, and communication of issues via standard channels including self-requesting CVE numbers for security bugs.

I encourage you to package a doas port, but urge you to choose opendoas in the process. :)

[danchr (Dan Villiom Podlaski Christiansen)]

At first glance, the points raised seem very valid to me. With regard to MacPorts, the main concern is whether it would be inappropriate to simply switch doas over to opendoas, without changing the port name, or to change the name? Both are reasonably easy to do, but the latter requires a compatibility subport.

The only thing I would do before just switching over to opendoas is investigate what FreeBSD has done. Personally, I’d consider them the canonical upstream for porting stuff from OpenBSD to macOS.

For the record, I found the slicer69 repository just by searching the 'net and GitHub. If you know the owner of the opendoas repository, I’d suggest converting it into something ​https://github.com/opendoas/opendoas — that would make it look more “official” to the next casual observer.

[danchr (Dan Villiom Podlaski Christiansen)]

FreeBSD also appears to use the slicer69 repository — I suspect that's how I found it to begin with. Have you also reported the issue to them? What was their response?

​https://www.freshports.org/security/doas/
​https://github.com/freebsd/freebsd-ports/blob/master/security/doas/Makefile

[eli-schwartz (Eli Schwartz)]

Maintainer: jsmith@…

​https://github.com/slicer69 is Jesse Smith whose company is Resonating Media.

slicer69 seems to be the person who originally submitted the FreeBSD port for his own software in ​https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210473 and continues to maintain it.

[danchr (Dan Villiom Podlaski Christiansen)]

In 3a180a6541b1b7544ad0ab88bd759c375b66ce8f/macports-ports (master):

opendoas: replacement for doas

Fixes: #62191