[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Source Signing
From:       Harald Sitter <sitter () kde ! org>
Date:       2019-09-19 11:23:54
Message-ID: CAEc+18FbmtoffzZ6uc8LdwWK9faQwbQs9VCVSgW+=qQhv09Q-g () mail ! gmail ! com
[Download RAW message or body]

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.

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.

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.

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?

We'd still need to figure out what exactly vetting entails. Could be
as simple as having access to a developer account on gitlab.

HS
[prev in list] [next in list] [prev in thread] [next in thread]