Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files

[Robin H. Johnson]

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).

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.

> > 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.

> > > 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.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer
E-Mail   : robbat2@g.o
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136