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
