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

[Michał Górny]

W dniu sob, 28.10.2017 o godzinie 18∶44 +0000, użytkownik Robin H.
Johnson napisał:
> On Sat, Oct 28, 2017 at 01:50:46PM +0200, Michał Górny wrote:
> > > A SVN or Git repo might also have dot-named directories.
> >
> > I like the implicit idea better as it is more consistent with normal
> > tool behavior, like 'ls' not listing the files. Dotfiles can be created
> > by many random tools or even the filesystem (especially in some cases
> > of overlay filesystems).
> >
> > That said, the case of 'lost+found' just occurred to me. I suppose this
> > one we will want to always IGNORE.
>
> Thought: make the package manager responsible for their own ignore list
> in addition to the IGNORE values; and by default it can contain a
> partial overlap with the IGNORE manifest entries.
> **/.git
> /lost+found # ignore at the top-level only
> /distfiles # ignore at the top-level only
> /packages # ignore at the top-level only
> /local # ignore at the top-level only
>
> 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.

>
> > Let's try:
> >
> > > 2. Start at the top-level Manifest file. Verify its OpenPGP signature.
> > >    Optionally verify the ``TIMESTAMP`` entry if present.
> > >    If the timestamp is significantly out of date compared to the local
> > >    clock or a trusted source, halt or require manual intervention
> > >    from the user. Remove the top-level Manifest from the *present* set.
> >
> > Maybe it would look better if I split it into sub-points.
>
> 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.

> > > 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*?

> > > > Timestamp field
> > >
> > > A malicious third-party may use the principles of exclusion and replay
> > > to deny an update to clients, while at the same time recording
> > > the identity of clients to attack. The timestamp field can be used
> > > to detect that.
> > >
> > > In order to provide a more complete protection, the Gentoo
> > > Infrastructure should provide an ability to obtain the timestamps
> > > of all Manifests from a recent timeframe over a secure channel
> > > for comparison.
> > >
> > > Strictly speaking, this is already provided by the various
> > > ``metadata/timestamp.*`` files provided already by Gentoo which are also
> > > covered by the Manifest. However, including the value in the Manifest
> > > itself has a little cost and provides the ability to perform
> > > the verification stand-alone.
>
> Just add in the sentence re trusted source from before, otherwise good.
> The rest of this thread devolved into specifics about implementing the
> validation; which aren't relevant to this GLEP (yes, telling the package
> manager that it's a known old tree, ignore the age only, is a valid use
> case).

Ok.

> > > Could we please note here, for the transitional period, that the
> > > file equivalence rule is applicable?
> > > During the transitional, the package Manifests may contain two entries for a
> > > given file: (DATA, EBUILD) or (DATA, AUX). The MISC type remains the
> > > same.
> >
> > Equivalence rule is applicable always. However, there's no point
> > in duplicating the entry for the same file as that's only going
> > to increase space use.
>
> This means that new verification tools (beyond Gemato) need to handle
> the legacy types for the moment, and can't just skip them (eg if both
> entries existed).

Which is the easier way forward. Otherwise, we end up having a lot of
duplication during the transition period (which would amount to 2 years
at the very least, and probably a lot more).

>
> > > > - the Manifest files inside the package directory can be signed
> > > >   to provide authenticity verification.
> > >
> > > Why do we need to specify this in backwards compat, it's still permitted above.
> >
> > 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.

-- 
Best regards,
Michał Górny