
<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:normal;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>