[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files
From:       Michał_Górny <mgorny () gentoo ! org>
Date:       2017-10-30 16:01:56
Message-ID: 1509379316.1517.3.camel () gentoo ! org
[Download RAW message or body]

W dniu nie, 29.10.2017 o godzinie 20∶54 +0000, użytkownik Robin H.
Johnson napisał:
> On Sun, Oct 29, 2017 at 07:47:41PM +0100, Michał Górny wrote:
> ...
> > > If users need other values, it's a package-manager config knob.
> > 
> > We don't want pre-EAPI times where things will fail out of the box
> > unless the user choose the one tool that got the whole list right
> > and/or configure it to account for default list.
> > 
> > I don't mind package manager providing the ability to ignore additional
> > entries but the spec should work out of the box too.
> 
> Ok, can we have a minor additions to the text then:
> - The package manager may support additional user-specified IGNORE
>   entries, for usage where a user's processes need to inject additional
>   files that would not be ignored by existing rules (e.g. user commits
>   the rsync tree to CVS with -kb).

Included.

> Notes:
> - distfiles/packages/local will be in IGNORE as distributed.
> - package-manager might add lost+found if they have a filesystem just
>   for the tree.

Not sure if we lost+found isn't actually common enough to be included
in the standard set. But I'm fine either way.

> > > Yes, put 'Verifying TIMESTAMP' into a new section as you added below,
> > > including the out-of-date part there; don't detail how to verify it in
> > > this section.
> > 
> > I will try to do this today.
> 
> Looks good.
> 
> > 
> > > > > GLEP61, for the transition period, required compressed & uncompressed Manifests
> > > > > in the same directory to have identical content. Include mention of that here.
> > > > 
> > > > Can do. But I'll do it in 'Backwards compatibility' section:
> > > > > - if the Manifest files inside the package directory are compressed,
> > > > >   a uncompressed file of identical content must coexist.
> > > > > Saying that either can be used is a potential issue.
> > > > 
> > > > Why? It also says that they must be identical, so it's of no difference
> > > > to the implementation which one is used.
> > > 
> > > It's safe if the identical requirement is there, and potentially unsafe otherwise.
> > 
> > That's why they're both put in a *single sentence*?
> 
> 'co-exist' in this context makes it the English parse weirdly to me,
> that's why I was worried at first.
> 
> Maybe a rewrite:
> An uncompressed Manifest file inside a package directory MUST exist
> during the transition period. A compressed Manifest of identical content
> MAY be present.

Done.

> 
> > > > But it makes no sense when top-level Manifest is signed. This points out
> > > > that for tools not supporting full-tree verification smaller signatures
> > > > need to be used (skipping the fact that Portage did not ever implement
> > > > it).
> > > 
> > > The Manifests might not be signed by the same entity.
> > > /metadata/glsa/Manifest might be signed by the security team, 
> > > /sec-policy/Manifest might be signed by SELinux team, 
> > > /Manifest should STILL be signed by Infra/tree-generation-process.
> > 
> > I honestly doubt this will ever happen, and even if it does, it isn't
> > really relevant to the spec at hand. My point was: if someone signs
> > the whole repository, he normally will consider it pointless to sign
> > individual package Manifests. This explains why he might consider it.
> 
> My argument is that it make sense to permit multiple levels of signature
> even when the top-level is signed: glsa-check could get ahead of the
> Portage curve by verifying /metadata/glsa/Manifest using Gemato :-).
> It doesn't need to verify the whole tree, just that directory.
> 
> The package manager should decide about the GPG-verification of the
> nested Manifests however, as they convey trust from different sources.

Sure. Gemato currently verifies all signed files it finds. However, it
only requires the top-level Manifest to be signed to consider the tree
signed.

I will submit an update once I process the other mail and do some
clarifications wrt OPTIONAL.

-- 
Best regards,
Michał Górny


[prev in list] [next in list] [prev in thread] [next in thread]