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

["Robin H. Johnson" <robbat2@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 5215 bytes --]

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.

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

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

> > > Tree design
> > > -----------
> > Add a minor header here, to say this is the end of the 'Tree design' section?
> It's not the end, it's description of the alternative. Both belong
> in one section. I could add additional section level but I'd rather
> not do that for a single use.
Hmm, just reads unclear if that should have been a different section.
Not sure if there is a nice way to fix it at all.

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


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

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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]