[MacPorts] #62191: doas 6.3p4: unreliable, antagonistic upstream with a bad security record

MacPorts noreply at macports.org
Sun Jan 31 20:54:53 UTC 2021


#62191: doas 6.3p4: unreliable, antagonistic upstream with a bad security record
--------------------------+--------------------
 Reporter:  eli-schwartz  |      Owner:  (none)
     Type:  defect        |     Status:  new
 Priority:  Normal        |  Milestone:
Component:  ports         |    Version:
 Keywords:                |       Port:
--------------------------+--------------------
 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)
 ([https://repology.org/project/doas/versions repology link])
 - https://github.com/Duncaen/OpenDoas/
 ([https://repology.org/project/opendoas/versions 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. :)

-- 
Ticket URL: <https://trac.macports.org/ticket/62191>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list