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 <[email protected]>" > > [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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
