------=_Part_8305282_1859393399.1568897393785 Date: Thu, 19 Sep 2019 14:49:53 +0200 (CEST) From: Tom Albers To: KDE release coordination Cc: sysadmin Message-ID: <563316380.8305280.1568897393722.JavaMail.zimbra@kovoks.nl> In-Reply-To: References: Subject: Re: Source Signing MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_a5a7cb2b-41c1-4f81-bcd7-62b8a85625e5" Thread-Topic: Source Signing Thread-Index: 67HYG2Hlx8z0VGiMsSjpJhz2A35Bbw== --=_a5a7cb2b-41c1-4f81-bcd7-62b8a85625e5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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 : > On Thu, Sep 19, 2019 at 1:24 PM Harald Sitter 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 --=_a5a7cb2b-41c1-4f81-bcd7-62b8a85625e5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=
I'ld also like to add that currently some dev= elopers have access to do releases directly - I've also seen those people p= utting the files on the ftp-server for other projects then the original int= ention had been.

I would like to propose that *all* releases should follow the below pr= oposal, effectively that would involve that the direct access would be canc= elled for those currently having access to the ftp-server directly.
<= div style=3D"font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #333333">This means an improved paper trail for those releases too and f= urther 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@kde.org>:
On Thu, Sep 19, 2019 at 1:24 PM Harald Sitter <sitter@kde.= org> wrote:
>
> At akademy we had a poorly attended bof abou= t release artifact
> signing. Jonathan raised the concern that while = we generally sign our
> stuff we do not actually verify the signature= s properly so coverage
> and reliability is dodgy at best.
> Th= is largely factors into what Friedrich raised a while ago in
> https:= //phabricator.kde.org/T11304.
>
> (The stuff below only partial= ly affects kf5,apps,plasma as their
> release processes are slightly = different...)
>
> To get a source tarball released any one pers= on 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 r= elease of our software.
> This is hugely informal.

It is corre= ct that there is no formally defined list of people who are
allowed to m= ake 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 an= d published.

It is correct that we do not validate the GPG signature= s submitted to us.

>
> And following the delivery pipeline,= the distributions then again have
> to employ informal checks to ver= ify 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
> s= hould keep a keyring of public "release keys", and before making
> th= eir first (source) release developers need to request release
> permi= ssion. That is to say they need to pop their gpg key somewhere
> (e.g= . gitlab) and sysadmins then need to "vet" this person before
> picki= ng the gpg key into their keyring.
>
> When someone uploads a s= ource tarball we can then require it to have
> an associated signatur= e. Sysadmins can gpg-verify the signature and by
> extension the uplo= aded artifact. Because of the keyring this could be
> fully automated= and replace the current (presumably manual) shasum
> checks and hope= fully 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 f= ile to be released.

The script then validates the hash, and if all i= s well prompts if it
is okay to proceed with moving the file to it's fin= al destination.

This provides a reasonable degree of assurance that = the file released
is the one that the person originally uploaded, but yo= u are correct
that it does not defend against attacks where someone's Id= entity
account has been compromised.

>
> On the distribu= tion 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 relea= se keyring would only contain vetted keys,
> demonstrating some minim= al trust already.
>
> An unfortunate side effect is that the re= lease process gets yet
> another step: getting your gpg key verified = by sysadmins. A one-time
> step, but a step nonetheless.
>
&= gt; 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 signi= ng
> system already, so requiring gpg on top of that is probably usel= ess.
>
> TLDR: no source releases without gpg signature, sysadm= ins maintain
> public keyring of developers who are allowed to releas= e and use it to
> verify uploads, distros can use keyring to verify d= ownloads
>
> What are your thoughts?

This seems reasonab= le 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 work= ed out all
potential issues and have a reasonably strong system in place= for
preventing bad things from happening)

With regards to the ke= yring itself however, how were you envisioning
this operating?

In= terms of how it would operate - were you thinking of it as a "this
pers= on is authorised to release any KDE software" or "this person is
authori= sed to release X, Y and Z bits of KDE software"?

>
> We'd s= till need to figure out what exactly vetting entails. Could be
> as s= imple 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 signe= d commits (which Gitlab has the ability to validate if
you let Gitlab kn= ow your key fingerprint)

>
> HS

Cheers,
Ben

--=_a5a7cb2b-41c1-4f81-bcd7-62b8a85625e5-- ------=_Part_8305282_1859393399.1568897393785 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIF BDCCA+ygAwIBAgIRALVJXeZa4rHgC/KdtJceLZwwDQYJKoZIhvcNAQELBQAwgZYxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNV BAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTkwNTA3MDAwMDAwWhcNMjIwNTA2MjM1OTU5 WjA0MRMwEQYDVQQDEwpUb20gQWxiZXJzMR0wGwYJKoZIhvcNAQkBFg50b21hQGtvdm9rcy5ubDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMoK4cn0U7UFW+oSIQ0hOF1W8IarhjtaQ8Yb tN4iIkL5bBx0XCbS/P4W1slbe7q+YDl4KrO7NrmlJfLFW1pEB6ER+KmdJG/cCGLa0UOaS2kuIWAb +rhSP4ZKtfAZQxBHUVhR8Y7oM/nCoeY6/AJRa+PxrSI8PO/xK3wOyZzuu66DeEYpgDdowot3rt0C nYozD8FnSGE3B3RLpcQAlmsT+0vpLjexPchxYFOs+gO/Sv1qiVpamI5L3BcvV6xS5jv64BJp9fc+ OMFqKp0y/bOqB13nSdFUMDtd5MIl2eaNfWW4ma7zQ1XOYi14V8nqboyyNekoNszsC1JYlEjyvFPP yv8CAwEAAaOCAawwggGoMB8GA1UdIwQYMBaAFAnA8vwL2pTbX/4r36iZQs/J4K0AMB0GA1UdDgQW BBQ/BmeQ7+ZJ23VHxeuHE4sWHtuSkjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwQAYDVR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAj BggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0 cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNl Y3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTANBgkqhkiG9w0BAQsFAAOC AQEAcjbx/8VgHGMCPcLNep8aIzwvBKNllvLTrCogqFh9EM1V8c96XxLBux1EiPcnBLWMd02vKWIt UHs5VLMzybU9juYMMzj0sNSI/yzYV47IBpkoGTNdA9goIaAPoNuA7mFQG/ru7FCFZ4tXS/4cqofO RmvcvHZh4zqtD041KxKVTICsTiB3nQUbg4ZBgpp38AaSorkA7PAjkJopns8zQcxATbTPKp2osZDc QRfZfkx0XV9SgP2IMiuOpWFPjenRexQ9Sf/sMkdqw0EaAnr1X9gHQvcSf//zbSANwPY6/GHQu7Vd D6BpRkDMxD1hBeM6f447H0mpASntLhEax8+ESdpDlgAAMYICqTCCAqUCAQEwgawwgZYxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAW BgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQC1SV3mWuKx4AvynbSXHi2cMA0GCWCGSAFl AwQCAQUAoIHOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDkx OTEyNDk1M1owLQYJKoZIhvcNAQk0MSAwHjANBglghkgBZQMEAgEFAKENBgkqhkiG9w0BAQsFADAv BgkqhkiG9w0BCQQxIgQghToeM26i7nl3X8s+TUxgkryR+cQmttuPVwHG9eCuDI8wNAYJKoZIhvcN AQkPMScwJTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYJKoZIhvcNAQEL BQAEggEARUr2U4LgbzO8ZOFxiDUvM8GvzVYARbXTmCh0eh+NirQt6kg+JN4Mq8CNRJjL+Y0Cfjlk GTyP73++YBX/rn3QJ8Qrj6vGj663ct1O4MyqPVclJ3zoSHzN5/R7BfUZq3e9r1xxfRjtA6XUnzIU OAbspn83KCffz5fQGh+3hS3tfTsCHZXF1qC9huJwJ3ZxN8ImFn/yI+QpF3RWyDgBYeKsJWMrhVOm oD98kKFoPsHr/cgFVZJ7l3kfdza2z6nxoVr37pnIVlVuPifnTgraDvCMXJVkJWHBJz9DiFJp48eJ YJlYaARzk2bexQY+5puXiY29As0Ekb5jpVf9znfgwTHpUQAAAAAAAA== ------=_Part_8305282_1859393399.1568897393785--