[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-release-team
Subject: Re: Source Signing
From: Tom Albers <toma () kde ! org>
Date: 2019-09-19 12:49:53
Message-ID: 563316380.8305280.1568897393722.JavaMail.zimbra () kovoks ! nl
[Download RAW message or body]
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@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 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
[Attachment #3 (text/html)]
<html><body><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; \
color: #333333"><div><style></style><style></style><style></style></div><div \
style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: \
#333333"><div></div>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. </div><div \
style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #333333"><br \
data-mce-bogus="1"></div><div style="font-family: arial,helvetica,sans-serif; \
font-size: 10pt; color: #333333">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. \
</div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: \
#333333">This means an improved paper trail for those releases too and further \
reduces the effect of compromised accounts and / or tarballs.<br><br><div \
data-marker="__SIG_PRE__">Best,<br><br>Tom Albers<br>KDE Sysadmin</div><br><span \
id="zwchr" data-marker="__DIVIDER__">----- Op 19 sep 2019 om 13:46 schreef Ben \
Cooksley <bcooksley@kde.org>:<br></span><div \
data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid \
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:norm \
al;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">On \
Thu, Sep 19, 2019 at 1:24 PM Harald Sitter <sitter@kde.org> \
wrote:<br>><br>> At akademy we had a poorly attended bof about release \
artifact<br>> signing. Jonathan raised the concern that while we generally sign \
our<br>> stuff we do not actually verify the signatures properly so \
coverage<br>> and reliability is dodgy at best.<br>> This largely factors into \
what Friedrich raised a while ago in<br>> \
https://phabricator.kde.org/T11304.<br>><br>> (The stuff below only partially \
affects kf5,apps,plasma as their<br>> release processes are slightly \
different...)<br>><br>> To get a source tarball released any one person can \
create a tarball,<br>> upload it to the relevant server and file a syadmin \
ticket.<br>> It is then upon the sysadmins to decide on a case by case basis if \
a<br>> given person should be allowed to even make a release of our \
software.<br>> This is hugely informal.<br><br>It is correct that there is no \
formally defined list of people who are<br>allowed to make releases of a given \
package.<br>For the most part, the checking process is reliant upon our \
knowledge<br>of who is involved with what project.<br><br>><br>> What's more as \
far as we are aware the sysadmins currently do not<br>> verify or require \
signatures, so if an identity account of a developer<br>> was compromised \
malicious releases could be uploaded and published.<br><br>It is correct that we do \
not validate the GPG signatures submitted to us.<br><br>><br>> And following \
the delivery pipeline, the distributions then again have<br>> to employ informal \
checks to verify the signatures, if they verify<br>> them at all.<br>><br>> \
To deal with these problems we, Albert, Jonathan and I, concluded that<br>> it \
would be a good idea to formalize this process. The sysadmins<br>> should keep a \
keyring of public "release keys", and before making<br>> their first (source) \
release developers need to request release<br>> permission. That is to say they \
need to pop their gpg key somewhere<br>> (e.g. gitlab) and sysadmins then need to \
"vet" this person before<br>> picking the gpg key into their \
keyring.<br>><br>> When someone uploads a source tarball we can then require it \
to have<br>> an associated signature. Sysadmins can gpg-verify the signature and \
by<br>> extension the uploaded artifact. Because of the keyring this could \
be<br>> fully automated and replace the current (presumably manual) shasum<br>> \
checks and hopefully make sysadmin's life easier.<br><br>While the process is manual \
in so far as a Sysadmin has to look at it,<br>the process has by-and-large been \
automated.<br><br>When someone submits a file for release, we run each \
hash/filename<br>pair through a script, which takes three parameters:<br>1) The \
destination of the file<br>2) The hash of the file<br>3) The name of the file to be \
released.<br><br>The script then validates the hash, and if all is well prompts if \
it<br>is okay to proceed with moving the file to it's final destination.<br><br>This \
provides a reasonable degree of assurance that the file released<br>is the one that \
the person originally uploaded, but you are correct<br>that it does not defend \
against attacks where someone's Identity<br>account has been \
compromised.<br><br>><br>> On the distribution side the keyring can be used to \
reduce the amount<br>> of trust-on-first-use that has to be put into a new key as \
the<br>> sysadmin's release keyring would only contain vetted keys,<br>> \
demonstrating some minimal trust already.<br>><br>> An unfortunate side effect \
is that the release process gets yet<br>> another step: getting your gpg key \
verified by sysadmins. A one-time<br>> step, but a step \
nonetheless.<br>><br>> Currently our stance is that none of this would apply to \
non-source<br>> releases because there may be conflicting signature systems \
already in<br>> place. Notable example is windows where .exes have their own \
signing<br>> system already, so requiring gpg on top of that is probably \
useless.<br>><br>> TLDR: no source releases without gpg signature, sysadmins \
maintain<br>> public keyring of developers who are allowed to release and use it \
to<br>> verify uploads, distros can use keyring to verify \
downloads<br>><br>> What are your thoughts?<br><br>This seems reasonable at \
first glance.<br><br>Given some of the submissions we receive, i'm a little hesitant \
to<br>fully automate the process (at least until we've worked out all<br>potential \
issues and have a reasonably strong system in place for<br>preventing bad things from \
happening)<br><br>With regards to the keyring itself however, how were you \
envisioning<br>this operating?<br><br>In terms of how it would operate - were you \
thinking of it as a "this<br>person is authorised to release any KDE software" or \
"this person is<br>authorised to release X, Y and Z bits of KDE \
software"?<br><br>><br>> We'd still need to figure out what exactly vetting \
entails. Could be<br>> as simple as having access to a developer account on \
gitlab.<br><br>I've a few ideas on how this might work - part of which may \
involve<br>using GPG signed commits (which Gitlab has the ability to validate \
if<br>you let Gitlab know your key fingerprint)<br><br>><br>> \
HS<br><br>Cheers,<br>Ben</blockquote></div></div><div><br></div></div></body></html>
["smime.p7s" (smime.p7s)]
0 *H
010
`He 0 *H
00 I]Z -0
*H
01 0 UGB10UGreater Manchester10USalford10U
Sectigo Limited1>0<U5Sectigo RSA Client Authentication and Secure Email CA0
190507000000Z
220506235959Z0410U
Tom Albers1 0 *H
toma@kovoks.nl0"0
*H
0
S[!
!8]V;ZC""Bl t\&[{`9x*6%[ZD$obCKi.!`R?JCGQXQ3 \
:Qk"<<+|ɜxF)7h \
w3gHa7tK kK.7=q`SJjZZK/WR;i>8j*2]IT0;] \
%}eCUb-xWn5(6 RXHS 00 U #0 ڔ_+ߨB 0 U ?gIuG ے0U \
0 U 0 0 U %0++0@U \
90705 +10%0#+https://sectigo.com/CPS0ZU S0Q0O M \
KIhttp://crl.sectigo.com/SectigoRSAClientAuthenticationandSecureEmailCA.crl0+ \
~0|0U+0Ihttp://crt.sectigo.com/SectigoRSAClientAuthenticationandSecureEmailCA.crt0#+0http://ocsp.sectigo.com0
*H
r6` c= z#</eӬ* \
X}Uz_ D'wM)b-P{9T3ɵ= 38Ԉ,W(3](! \
ۀaPPgWK Fkܼva:N5+LN \
wAw #)3A@M*A~Lt]_R2+aO{=I2GjAz_Bm \
:aл] iF@=a:; I).τIC 10001 0 UGB10UGreater \
Manchester10USalford10U Sectigo Limited1>0<U5Sectigo RSA Client \
Authentication and Secure Email CA I]Z -0 `He 0 *H
1 *H
0 *H
1
190919124953Z0- *H
41 0 0
`He
*H
0/ *H
1" : 3nyw_>ML`&ۏW 04 *H
1'0%0
*H
0*H
0+0
*H
EJSo3dq5/3V EӘ(tz -H>$ D~9d<`}'+ƏrN̪=W%'|H|{w\q}ԟ287('ϗ -}; \
p'vq7 &#)tV8a%c+S ?|h>U{y w6ϩZVUn>'N \
\d%a'?CRilj`Xhsf>曗cWw1Q
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic