I'ld also like to add that currently some developers have access to do releases directly - I've also seen those people putting the files on the ftp-server for other projects then the original intention had been.
I would like to propose that *all* releases should follow the below proposal, effectively that would involve that the direct access would be cancelled for those currently having access to the ftp-server directly. This means an improved paper trail for those releases too and further reduces the effect of compromised accounts and / or tarballs. Best, Tom Albers KDE Sysadmin ----- Op 19 sep 2019 om 13:46 schreef Ben Cooksley <[email protected]>: > On Thu, Sep 19, 2019 at 1:24 PM Harald Sitter <[email protected]> wrote: > > 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. > It is correct that there is no formally defined list of people who are > allowed to make releases of a given package. > For the most part, the checking process is reliant upon our knowledge > of who is involved with what project. > > 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. > It is correct that we do not validate the GPG signatures submitted to us. > > 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. > While the process is manual in so far as a Sysadmin has to look at it, > the process has by-and-large been automated. > When someone submits a file for release, we run each hash/filename > pair through a script, which takes three parameters: > 1) The destination of the file > 2) The hash of the file > 3) The name of the file to be released. > The script then validates the hash, and if all is well prompts if it > is okay to proceed with moving the file to it's final destination. > This provides a reasonable degree of assurance that the file released > is the one that the person originally uploaded, but you are correct > that it does not defend against attacks where someone's Identity > account has been compromised. > > 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? > This seems reasonable at first glance. > Given some of the submissions we receive, i'm a little hesitant to > fully automate the process (at least until we've worked out all > potential issues and have a reasonably strong system in place for > preventing bad things from happening) > With regards to the keyring itself however, how were you envisioning > this operating? > In terms of how it would operate - were you thinking of it as a "this > person is authorised to release any KDE software" or "this person is > authorised to release X, Y and Z bits of KDE software"? > > We'd still need to figure out what exactly vetting entails. Could be > > as simple as having access to a developer account on gitlab. > I've a few ideas on how this might work - part of which may involve > using GPG signed commits (which Gitlab has the ability to validate if > you let Gitlab know your key fingerprint) > > HS > Cheers, > Ben
smime.p7s
Description: S/MIME Cryptographic Signature
