On Sun, May 01, 2011 at 04:31:08PM -0700, Brian Harring wrote: > On Sun, May 01, 2011 at 11:23:40PM +0000, Duncan wrote: > > 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. > > It means the only real trust that clients can level is on that key- > since it will be the last signer (thus /the/ signer) across all pkgs. > > Get at that key, and you've got the tree, versus the current form, > crack all signing keys and you've got the tree. > > Mind you this is ignoring eclasses, but getting eclasses sorted will > be mildly pointless if the rest of the solution has been > weakened/gutted since. > > Point is, it's not *just* about having a signature on it- it's about > mapping the trust of that signature back, and sectioning/containing > compromises. What y'all are suggesting guts that layered defense. > ~brian
Then the only choice here is to ignore Changelogs from Manifests and live with that. You have your changelogs unprotected but you keep your ebuilds safe(?). As I said, it is a balanced choice that has to be made. Regards, -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
pgpggJYfi62pV.pgp
Description: PGP signature
