Gregory's ServerIt's not very popular, but I wonder if signing release tarballs with the release manager's private key would go some ways towards alleviating xz-esque woes, at the very least making distros aware that an upstream has changed hands and having to do due diligence to fix their builds
Drew DeVault
19 comments
Jon Yoder
@drewdevault I worked on that exact problem for my passion project, one which replaces e-mail, and I think I did pretty good, but I wonder what you think of the solution. The spec repo is at https://gitlab.com/mensago/mensago-docs and the two relevant documents are the platform overview (for context) and the Identity Services API, which goes into detail about how it's done. I know you're quite busy, but thought you might find the concepts interesting.
Kevin
@drewdevault according to https://tukaani.org/xz-backdoor/ this was already the case. "Tarballs created by Jia Tan were signed by him. Any tarballs signed by me were created by me."
Drew DeVault
@ikke well, did anyone downstream verify the signatures? I only know of Arch Linux as incorporating upstream release signatures into their build process, and they do so inconsistently. So even if they were signed I don't think that means there are processes to do due diligence
Kevin
@drewdevault a new maintainer can do one or more innocent releases. Their keys are trusted, and then they can start incorporating malicious changes.
Drew DeVault
@ikke indeed, but at least it makes it a matter of record when the handover applied to a downstream distro, and gives you an opportunity to say "hm... that guy showed up out of nowhere and took over this critical low-level project, something smells..." I would have been suspicious of this even from the initial hand-over, *if* I had done the due diligence, so making that part of the process might be a good idea? 
Moritz Poldrack :arch:
@drewdevault I don't think so. While it is certainly useful, signing the tarballs doesn't help. Since the perpetrator had a position of trust, this would still have happened.
Drew DeVault
I think there's also something to be said for the release tarballs being reproducible, since we have git there's not much reason not to. Some release processes have codegen and cleanup steps involved before the release tarball is cut from git, but those can be made deterministic and verifiable
Drew DeVault
I'll add that, on behalf of distro maintainers everywhere, we don't really mind running autoreconf or whatever against a raw tarball fetched from a git tag, as it were, and dealing with these codegen/release prep bits ourselves as a part of the package building process. Perhaps we should be fetching git tarballs and doing this work ourselves unilaterally rather than relying on upstream-prepared release tarballs anyway? The target audience for those is the casual/ad-hoc builds anyway. 
Janne Moren
@drewdevault We download maintainer-supplied tarballs of releases if available. If not, we clone the repo and check out the tag or commit corresponding to the release, then build from that.
Drew DeVault
Though we would definitely be cool with it if you took this opportunity to deprecate autotools everywhere so we never have to work with it again!
Drew DeVault
@rincewind depends on your needs but I might suggest that https://muon.build is the most general
rincewind
@drewdevault well, in my case that would monitoring-plugins.org which relies heavily on several different libs and command line utilities. 
Drew DeVault
@bayindirh incredibly complex and obtuse and poorly designed and solves problems that we mostly don't have and those that we do have other tools solve much better 
hexaheximal
@drewdevault The disappointing truth is that while autotools *is* bad, the modern alternatives are far worse. (e.g. CMake) 
mort
@drewdevault Considering autotools changes aren't backwards compatible, this sounds like hell tbh >_> you'd need many versions of autotools and be able to select between them based on which version range each project's configure.ac/Makefile.am file works with Alternatively, GNU could just take their bloody role as core infrastructure maintainer seriously and stop breaking stuff all the time, but I don't see that happening any time soon |
Though key distribution is, as always, the main problem here