Source Signing

[Tom Albers]

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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20190919/f55552c3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2035 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.kde.org/pipermail/release-team/attachments/20190919/f55552c3/attachment-0001.bin>