Re: [gentoo-dev] [enhancement proposal] Per-file Manifest GPG signatures

["Robin H. Johnson" <robbat2@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3508 bytes --]

On Sun, Oct 03, 2010 at 09:58:48AM +0200, Micha?? G??rny wrote:
> The current signing approach gives all the responsibility for Manifest
> signature to the developer who committed last update to the ebuild
> directory regardless of the actual commit significance.
> 
> Consider the following: Dev A is the primary package maintainer. He/she
> reviewed all the ebuilds and committed a signed Manifest. Then Dev B
> performs a slight cleanup of the ebuild directory. He/she modifies
> metadata.xml a little and/or removes an old ebuild.
> 
> The actual ebuilds weren't modified -- yet Dev B has to sign all
> of them once again. Moreover, if Dev B doesn't use Manifest signing,
> the signature from Dev A is lost.
This exact problem was raised in 2003, as some of the early tree-signing
discussion. If you haven't read my endnote to GLEP57, I strongly
encourage you to do so.

The end question from many of those discussions, on the matter of
internal signature in the Manifest was:
Why are VCS annotations on the unchanged files not enough?
$ cvs annotate Manifest
That can clearly show you the lines that have not changed, regardless of
how many times the Manifest is signed and resigned.

The best (and simultaneously worse) solution that turned up in the prior
versions was the proposed appending of new data to Manifests, not
replacing. The new data had to be signed however, otherwise it opened up
a new way to exploit the security. And if you're signing the new data,
there is no problem to just resign all of it.

> The solution
> ------------
I would like to thank you for a new insight into the problem.
Your solution is sufficiently novel that none of the prior proposals are
anything like it.

> As a solution for this I suggest making the GPG signatures per-file,
> simply creating an additional hash type for them. For example,
> a single Manifest line would look like:
> 
> EBUILD foo-1.ebuild 1000 RMD160 ... SHA1 ... SHA256 ... GPG ...
I'm assuming you are proposing taking the ascii-armoured detached
signature here, stripping the newlines (except the last one, which needs
to be kept as a separate field), and using that.

Alternatively base64 encode the non-armoured binary detached signature
ourselves. Very little difference in the two ultimately however.

> Where the GPG signature will be an explicit signature done by the dev
> modifying (or reviewing) a particular file. Then, if another dev
> modifies a single file, the signatures for other files would be
> untouched.

> Potential issues
> ----------------
> This signing model does not provide a mechanism for signing file
> removals. In other words, if a dev does remove files only, he/she won't
> leave any signature changes at all. If there's a reason to do that, we
> can consider using a complete Manifest file signature in parallel.
Some more issues for you:
1. Increases the size of the Manifest by a minimum of 710 bytes _per_
   file. (4 bytes for 'GPG ', 700-900 for the hash, 1 for the field space, 5-12 bytes for the
   trailer).
1.1. 55907 Manifest2 entries need this signing, so that's a ~38MiB
     increase in the tree size.
2. Impossible to validate without Portage itself, or at least another
   tool to convert the signature back into a form readable by GnuPG.


-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]