At akademy we had a poorly attended bof about release artifact signing. Jonathan raised the concern that while we generally sign our stuff we do not actually verify the signatures properly so coverage and reliability is dodgy at best. This largely factors into what Friedrich raised a while ago in https://phabricator.kde.org/T11304.
(The stuff below only partially affects kf5,apps,plasma as their release processes are slightly different...) To get a source tarball released any one person can create a tarball, upload it to the relevant server and file a syadmin ticket. It is then upon the sysadmins to decide on a case by case basis if a given person should be allowed to even make a release of our software. This is hugely informal. What's more as far as we are aware the sysadmins currently do not verify or require signatures, so if an identity account of a developer was compromised malicious releases could be uploaded and published. And following the delivery pipeline, the distributions then again have to employ informal checks to verify the signatures, if they verify them at all. To deal with these problems we, Albert, Jonathan and I, concluded that it would be a good idea to formalize this process. The sysadmins should keep a keyring of public "release keys", and before making their first (source) release developers need to request release permission. That is to say they need to pop their gpg key somewhere (e.g. gitlab) and sysadmins then need to "vet" this person before picking the gpg key into their keyring. When someone uploads a source tarball we can then require it to have an associated signature. Sysadmins can gpg-verify the signature and by extension the uploaded artifact. Because of the keyring this could be fully automated and replace the current (presumably manual) shasum checks and hopefully make sysadmin's life easier. On the distribution side the keyring can be used to reduce the amount of trust-on-first-use that has to be put into a new key as the sysadmin's release keyring would only contain vetted keys, demonstrating some minimal trust already. An unfortunate side effect is that the release process gets yet another step: getting your gpg key verified by sysadmins. A one-time step, but a step nonetheless. Currently our stance is that none of this would apply to non-source releases because there may be conflicting signature systems already in place. Notable example is windows where .exes have their own signing system already, so requiring gpg on top of that is probably useless. TLDR: no source releases without gpg signature, sysadmins maintain public keyring of developers who are allowed to release and use it to verify uploads, distros can use keyring to verify downloads What are your thoughts? We'd still need to figure out what exactly vetting entails. Could be as simple as having access to a developer account on gitlab. HS
