[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: digital signatures for kde sources?
From:       Sune Vuorela <nospam () vuorela ! dk>
Date:       2010-05-26 11:15:20
Message-ID: slrnhvq0m8.rvp.nospam () sshway ! ssh ! pusling ! com
[Download RAW message or body]

On 2010-05-26, Tom Albers <toma@kde.org> wrote:
> Sure, but those commits go to a mailinglist, so everyone can check what
> goes in. Detecting that a tarball has changed (or MITM) results in no
> commit message to any list. Changing the published sha1sums is a lot harder
> btw, as those are in svn too. But I don't think many check sha1sums.
>
> If the workflow is anywhere near sane for signing tarballs, I agree we
> should do them. 

1) check that the tarballs are sane.

2) generate some checksums
sha256sum *.tar.gz > sha256-sums

3) sign the checksums
gpg --clearsign sha256-sums

4) publish the signed checksums and the tarbaals
scp *.tar.gz sha256-sums.asc ktown:path

5) profit.


Alternatively, sign each tarball separately, but in a human unreadable
format

1) check that the tarballs are sane

2) sign tarbaals
for i in *.tar.gz ; do gpg -b $i ; done 

3) publish tarballs and signatures
scp *.tar.gz *.sig ktown:path

4) profit.



To validate:

First you need to establish a trust path to the key used to sign the
sources. This is the hard step.

either:
download tarballs and sha256 sums
gpg --verify sha256-sums.asc
sha256sum -c sha256-sums.asc
profit

or, if each tarball is signed individually
download tarballs and sig natures
for i in *.tar.gz ; do gpg --verify $i.sig $i ; done
profit


But verifying still fails on 'establish trust path to whoever signs it'.
Everyone can create a key saying "dirk mueller <dirk@something>", so it
kind of needs verifications.

/Sune

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]