Conversation

Notices

1. Embed this notice
   Drew DeVault (drewdevault@fosstodon.org)'s status on Tuesday, 02-Apr-2024 19:38:12 JST Drew DeVault

   It'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

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Tuesday, 02-Apr-2024 19:38:09 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Kevin
     @drewdevault @ikke Gentoo has upstream key verification supported, in fact with the keys being packaged so keyservers woes are avoided (and signify/minisign is supported).
     
     Sad part is more that the vast majority of software releases aren't signed at all or when they are, you have to hunt for the key rather than having it maintained at a known and verified location.
   • Embed this notice
     Drew DeVault (drewdevault@fosstodon.org)'s status on Tuesday, 02-Apr-2024 19:38:10 JST Drew DeVault

     in reply to

     • Kevin

     @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

   • Embed this notice
     Kevin (ikke@ipv6.social)'s status on Tuesday, 02-Apr-2024 19:38:11 JST Kevin

     in reply to

     @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."

   • Embed this notice
     Drew DeVault (drewdevault@fosstodon.org)'s status on Tuesday, 02-Apr-2024 19:38:54 JST Drew DeVault

     in reply to

     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.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Drew DeVault (drewdevault@fosstodon.org)'s status on Tuesday, 02-Apr-2024 19:38:55 JST Drew DeVault

     in reply to

     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

   • Embed this notice
     mort (mort@fosstodon.org)'s status on Tuesday, 02-Apr-2024 19:39:46 JST mort

     in reply to

     @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

     Haelwenn /элвэн/ :triskell: likes this.