tarball signing

[Martin Graesslin]

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 
escriure:
> > 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 [1]
> > 
> > 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
> tarballs?

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 
managers.

Of course it's only a way to mitigate the risk that even that is completely 
faked ;-)

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20160603/ef2506e6/attachment.sig>