Source Signing

[Albert Astals Cid]

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 <bcooksley at kde.org>: 
> 
> > On Thu, Sep 19, 2019 at 1:24 PM Harald Sitter <sitter at kde.org> 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