El dijous, 19 de setembre de 2019, a les 14:49:53 CEST, Tom Albers va escriure: > 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.
-1 this just makes it harder for us that have 200 packages to release for no real reason. If my gpg/ssh keys gets compromised, what difference does it make that i upload directly to the ftp-server or to the "sysadmin please upload this" server? Cheers, Albert > > 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
