Markos Chandras posted on Sun, 01 May 2011 23:49:06 +0100 as excerpted: > On Sun, May 01, 2011 at 03:33:25PM -0700, Brian Harring wrote: >> On Sun, May 01, 2011 at 10:08:31PM +0100, Markos Chandras wrote: >>> Since most ( if not all ) of us use the same message on the Changelog >>> and on the commit log, it probably worth the effort of having the >>> rsync servers create the Changelogs before populate the portage tree.
>> This opens up a bit of nastyness; either the service would have to >> resign all manifests (which defeats a fair bit of the signing intent), >> or ChangeLog's would have to pulled in full from cvs, generated >> strictly server side (else manifest will have stale chksums for it), >> and ChangeLog will have to exist outside of all validation. > Thats a fair point but the way I see it we need to make a balanced > choice. Obviously is not feasible to have the rsync servers resign > everything. [But] having all the gpg keys on the rsync servers [...] > doesn't look that smart to me. > Leaving Changelogs unprotected might be a bit of a trouble but it > certainly is not that big a deal. Nothing serious can happen if someone > hijacks a plain text file. > In case people want to ensure end-to-end point integrity, we can use > a separate GPG key for the rsync server. However, this will make our GPG > keys useless, and having a single key to sing 10.000 Manifest files does > not look good either. What about having a dedicated server-based changlog-signing key? That's still a lot of signing with a single key, but as you observed, the hazards of a loss of integrity there aren't as high as with most of the tree content. It'd require changes, but I don't believe they're out of line with that required for the rest of the proposal. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman