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 92AF21396D9 for ; Sat, 28 Oct 2017 18:44:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0A168E0D90; Sat, 28 Oct 2017 18:44:49 +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 A6565E0D4E for ; Sat, 28 Oct 2017 18:44:48 +0000 (UTC) Received: from grubbs.orbis-terrarum.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id C094033C770 for ; Sat, 28 Oct 2017 18:44:44 +0000 (UTC) Received: (qmail 17758 invoked by uid 10000); 28 Oct 2017 18:44:42 -0000 Date: Sat, 28 Oct 2017 18:44:42 +0000 From: "Robin H. Johnson" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files Message-ID: References: <1509048745.18656.6.camel@gentoo.org> <1509191446.1791.24.camel@gentoo.org> 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-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zFHfQTJdDMtDGy0L" Content-Disposition: inline In-Reply-To: <1509191446.1791.24.camel@gentoo.org> User-Agent: Mutt/1.8.2 (2017-04-18) X-Archives-Salt: 6564069d-f267-4b98-839f-e5a01d707ee5 X-Archives-Hash: b84c9f7f24093bdcd612625d9ce1c5c0 --zFHfQTJdDMtDGy0L Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 28, 2017 at 01:50:46PM +0200, Micha=C5=82 G=C3=B3rny 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). >=20 > 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: >=20 > | 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. >=20 > 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 M= anifests > > in the same directory to have identical content. Include mention of tha= t 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 oth= erwise. > > > Tree design > > > ----------- > > Add a minor header here, to say this is the end of the 'Tree design' se= ction? > 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?=20 > > 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 permitte= d 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,=20 /sec-policy/Manifest might be signed by SELinux team,=20 /Manifest should STILL be signed by Infra/tree-generation-process. --=20 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 --zFHfQTJdDMtDGy0L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Robbat2 @ Orbis-Terrarum Networks - The text below is a digital signature. If it doesn't make any sense to you, ignore it. iQKTBAEBCgB9FiEEveu2pS8Vb98xaNkRGTlfI8WIJsQFAln00BpfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEJE RUJCNkE1MkYxNTZGREYzMTY4RDkxMTE5Mzk1RjIzQzU4ODI2QzQACgkQGTlfI8WI JsRtQA//c94iUlWwqzHdJ8EpSgIWj3B1T8RtCTLRZVclc7ri9McqZbyZpUwdVDHv wyk+e5G2HUtmu92MeESaJaHqYF1IUWqXucF4PnBh5hX5ssMcqs+U/oO2P7n2r3Zd wt0gjpyQtUoecAfD2b600aL3dQX6rEwjeo2+PHuX5qz0pGbLMbkvMVRbU6iv13dk FgT8ypfnFm914+7lpFgmG973b9huvFsxT6YJpCSbqMNHCReHGWnrOxpRQTdZUGUT OF02Nsu5hF7rhctF1JVp622N/LTprQsI9E0zlYJD10wmYyekjHG0DCxttOYhBumJ DUWXDjfI7csE5J4MGkoLtTFIGD3mn2FJl7lkK2I+Q7Lk+0tMk/xNwexUTOcoa4mH TS8xd+nR3O/D4MpPy3xr6zhY6pCjxjDMWJNNsfi9Gm4rWgG00FKJn3aNC5njbcDI byjygrPKcGsagV+fDvY+/bMbYs4PJX2BI6QHCxk9fWq3G0D8jLc9e1b2AEcqOTKl y4VamUCAiZ3dCSnCv3ZCC5DyIzkrjAOAU3gIesSdJ7EQ3m7U6ZyA+4wiRhqNODnn thICvnG2akkstGWCTlTWXYpwhr5mtdNc/Hh7Vuec/oyZwRgdC0KIzMZsqDZIvq4K Fxi2NICqfYdOiCNzkvVL/zW+69owHrUdLtvGF3LaXjupo5P0XEI= =L379 -----END PGP SIGNATURE----- --zFHfQTJdDMtDGy0L--