Source Signing

[Ben Cooksley]

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