Re: [gentoo-dev] Re: Devmanual text on ChangeLogs

[Arfrever Frehtes Taifersar Arahesis]

2011-05-02 02:16:49 Markos Chandras napisał(a):
> 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.

Generated ChangeLogs could contain server-side-generated signatures for themselves
(gpg --sign --clearsign ChangeLog && mv ChangeLog.asc ChangeLog). 
(Manifests wouldn't contain entries for ChangeLogs.)

-- 
Arfrever Frehtes Taifersar Arahesis