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 D83BC1396D9 for ; Mon, 30 Oct 2017 16:02:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D77B2E100F; Mon, 30 Oct 2017 16:02:02 +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 82E3CE0FC8 for ; Mon, 30 Oct 2017 16:02:02 +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 74E203416ED; Mon, 30 Oct 2017 16:02:00 +0000 (UTC) Message-ID: <1509379316.1517.3.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: Mon, 30 Oct 2017 17:01:56 +0100 In-Reply-To: References: <1509048745.18656.6.camel@gentoo.org> <1509191446.1791.24.camel@gentoo.org> <1509302861.14897.15.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: 1736078f-f42e-4cdc-a025-5dbe586b376a X-Archives-Hash: b3e30b13239bd063f94fae02da157b05 W dniu nie, 29.10.2017 o godzinie 20∶54 +0000, użytkownik Robin H. Johnson napisał: > On Sun, Oct 29, 2017 at 07:47:41PM +0100, Michał Górny wrote: > ... > > > 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. > > Ok, can we have a minor additions to the text then: > - The package manager may support additional user-specified IGNORE > entries, for usage where a user's processes need to inject additional > files that would not be ignored by existing rules (e.g. user commits > the rsync tree to CVS with -kb). Included. > Notes: > - distfiles/packages/local will be in IGNORE as distributed. > - package-manager might add lost+found if they have a filesystem just > for the tree. Not sure if we lost+found isn't actually common enough to be included in the standard set. But I'm fine either way. > > > 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. > > Looks good. > > > > > > > > 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*? > > 'co-exist' in this context makes it the English parse weirdly to me, > that's why I was worried at first. > > Maybe a rewrite: > An uncompressed Manifest file inside a package directory MUST exist > during the transition period. A compressed Manifest of identical content > MAY be present. Done. > > > > > 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. > > My argument is that it make sense to permit multiple levels of signature > even when the top-level is signed: glsa-check could get ahead of the > Portage curve by verifying /metadata/glsa/Manifest using Gemato :-). > It doesn't need to verify the whole tree, just that directory. > > The package manager should decide about the GPG-verification of the > nested Manifests however, as they convey trust from different sources. Sure. Gemato currently verifies all signed files it finds. However, it only requires the top-level Manifest to be signed to consider the tree signed. I will submit an update once I process the other mail and do some clarifications wrt OPTIONAL. -- Best regards, Michał Górny