| 1 |
On Sun, May 01, 2011 at 04:31:08PM -0700, Brian Harring wrote: |
| 2 |
> On Sun, May 01, 2011 at 11:23:40PM +0000, Duncan wrote: |
| 3 |
> > What about having a dedicated server-based changlog-signing key? That's |
| 4 |
> > still a lot of signing with a single key, but as you observed, the hazards |
| 5 |
> > of a loss of integrity there aren't as high as with most of the tree |
| 6 |
> > content. It'd require changes, but I don't believe they're out of line |
| 7 |
> > with that required for the rest of the proposal. |
| 8 |
> |
| 9 |
> It means the only real trust that clients can level is on that key- |
| 10 |
> since it will be the last signer (thus /the/ signer) across all pkgs. |
| 11 |
> |
| 12 |
> Get at that key, and you've got the tree, versus the current form, |
| 13 |
> crack all signing keys and you've got the tree. |
| 14 |
> |
| 15 |
> Mind you this is ignoring eclasses, but getting eclasses sorted will |
| 16 |
> be mildly pointless if the rest of the solution has been |
| 17 |
> weakened/gutted since. |
| 18 |
> |
| 19 |
> Point is, it's not *just* about having a signature on it- it's about |
| 20 |
> mapping the trust of that signature back, and sectioning/containing |
| 21 |
> compromises. What y'all are suggesting guts that layered defense. |
| 22 |
> ~brian |
| 23 |
|
| 24 |
Then the only choice here is to ignore Changelogs from Manifests and |
| 25 |
live with that. You have your changelogs unprotected but you keep your |
| 26 |
ebuilds safe(?). As I said, it is a balanced choice that has to be made. |
| 27 |
|
| 28 |
Regards, |
| 29 |
-- |
| 30 |
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 |
Archives