mgraesslin at kde.org
Fri Jun 3 14:09:45 UTC 2016
On Friday, June 3, 2016 4:02:43 PM CEST Albert Astals Cid wrote:
> El dijous, 2 de juny de 2016, a les 13:53:46 CEST, Harald Sitter va
> > Ahoy
> > At last weekends' Munich sprint, Jonathan and I discussed the
> > possibility of detached-signing our tarballs. Right now people have to
> > go to some website, get checksums, and then verify the downloaded
> > tarballs matches the checksums.
> > This is not only terrible because it involves humans doing things, it
> > is also terrible as there is no way to tell whether or not the data on
> > the website is even authoritative, in particular for extragear where
> > this information might not even be under https certification and even
> > if it was who's to say the webserver hasn't been compromised.
> > Add that our tarball mirrors are often distributing over http or ftp
> > and getting an authoritative tarball is more luck than consistent
> > checks.
> > And that is why we should sign our tarballs and we agreed to start
> > doing that soonishy for Plasma tarballs (or rather: releasme in
> > general) and would like to encourage everyone to build appropriate GPG
> > signing tech into their release scripts. At the very least frameworks
> > and apps would be beneficial to cover with signatures.
> > It allows us to easily verify file integrity as well as file
> > trustworthyness as either of the two not adding up would result in a
> > verification failure.
> > So how's that work?
> > Relevant starting documentation can be found at 
> > I would for example run
> > $ gpg2 --digest-algo SHA512 --armor --detach-sign -o
> > phonon-4.9.0.tar.xz.sig -s phonon-4.9.0.tar.xz
> > This generates a .sig file for the phonon 4.9 tarball.
> > Which I can then verify
> > $ gpg2 -q --verify -q phonon-4.9.0.tar.xz.sig phonon-4.9.0.tar.xz; echo $?
> > gpg: Signature made Don 02 Jun 2016 13:34:35 CEST using DSA key ID
> > 72F23991
> > gpg: Good signature from "Harald Sitter <apachelogger at ubuntu.com>"
> > [ultimate]
> > Now then. In the grand scheme of things we'd only ship tarballs with a
> > relevant sig in the same directory. A consumer of our tarballs (e.g. a
> > linux distribution) would grab our tarball *and* the sig and ensure
> > that the sig is an authoritatively trusted key (e.g. part of a keyring
> > with trusted keys).
> > If the verification succeeds the tarball is good to be used, if not
> > human intervention is required to investigate.
> Does that really fix anything if noone has my gpg key in the
> trusted/validated signatures area? How do they know it's me that signed the
> package and not some hacker that got access to the server and did sign the
if it's signed with the same key as the git tag? That could give some hints
that it must be legit.
Otherwise: we could make another gpg key signing party and ensure that we get
lots of signatures to your key. Maybe also extend it: get distros sign the key
of our release managers. So that we do have a nice chain of trust for release
Of course it's only a way to mitigate the risk that even that is completely
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: This is a digitally signed message part.
More information about the release-team