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 : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
signature.asc
Description: Digital signature
