From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id CD36E1396D9 for ; Sun, 29 Oct 2017 18:47:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B88D62BC076; Sun, 29 Oct 2017 18:47:46 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5D046E0E4C for ; Sun, 29 Oct 2017 18:47:46 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 922B73416A8; Sun, 29 Oct 2017 18:47:44 +0000 (UTC) Message-ID: <1509302861.14897.15.camel@gentoo.org> Subject: Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Sun, 29 Oct 2017 19:47:41 +0100 In-Reply-To: References: <1509048745.18656.6.camel@gentoo.org> <1509191446.1791.24.camel@gentoo.org> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.5 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: d7b13e45-f3fd-446a-9b19-730df7961a30 X-Archives-Hash: c9a655a26e1db9c253aec58b6ab5de9a 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