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 7A4861396D9 for ; Sun, 29 Oct 2017 20:54:20 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 24D97E0EC6; Sun, 29 Oct 2017 20:54:15 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 BEF4BE0EBA for ; Sun, 29 Oct 2017 20:54:14 +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 DC52E3416B5 for ; Sun, 29 Oct 2017 20:54:13 +0000 (UTC) Received: (qmail 1762 invoked by uid 10000); 29 Oct 2017 20:54:12 -0000 Date: Sun, 29 Oct 2017 20:54:12 +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> <1509302861.14897.15.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="2VcK7Ezgm4IMdfSa" Content-Disposition: inline In-Reply-To: <1509302861.14897.15.camel@gentoo.org> User-Agent: Mutt/1.8.2 (2017-04-18) X-Archives-Salt: a5ba09fe-de34-479a-850b-2686aee8c713 X-Archives-Hash: 3671bd3289e38f643d034b01c59f5e9c --2VcK7Ezgm4IMdfSa Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 29, 2017 at 07:47:41PM +0100, Micha=C5=82 G=C3=B3rny wrote: =2E.. > > If users need other values, it's a package-manager config knob. >=20 > 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. >=20 > 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). 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. > > 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. >=20 > > > > GLEP61, for the transition period, required compressed & uncompress= ed Manifests > > > > in the same directory to have identical content. Include mention of= that here. > > >=20 > > > 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. > > >=20 > > > Why? It also says that they must be identical, so it's of no differen= ce > > > to the implementation which one is used. > >=20 > > 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. > > > But it makes no sense when top-level Manifest is signed. This points = out > > > that for tools not supporting full-tree verification smaller signatur= es > > > 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. > 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. --=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 --2VcK7Ezgm4IMdfSa 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. iQKTBAEBCgB9FiEEveu2pS8Vb98xaNkRGTlfI8WIJsQFAln2P/NfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEJE RUJCNkE1MkYxNTZGREYzMTY4RDkxMTE5Mzk1RjIzQzU4ODI2QzQACgkQGTlfI8WI JsQBmQ/7BkkUh3s87eVhSwtDuucQNiVuwzH0RUapfrkTlYdfPmEYrBRbDoo5SneC HTdVBGMAm3AJpMutzE5QZML+SwMyqqzNmjPbIoJFW/DvTyf/aKa4Q2/4xI4Lu/X6 FluXgMvpAHMQtv6fO6fEtkdW9gQ6YADc1X9M4YiOXvnVkt6lGsM1lwXTPsMGuKH9 nq9E9JayebJdQtEekKjwoOpXRkbeZG6V42f+9PfCLMLZeqO+P7QCVK28KGbNF0Wy uSCaiUqkwYQCBjGa+L5ii6ie9uGUlUMUQ/zHf3E/uc1/f1cbRofVJPAKfo5x76Hy 1/UT0mpAnayNApzNwq4aln5x4AgIGWd362XgODxjloNzBTRCLGDvP1zyZTSaxHqJ CVRWWpItcwB/5DUckQeVkBCIkzDZclTPeqiC9PhDiX3hdWsAcjmmZ5EdPGUA7DTL ghUya/viabCvux83AU/yMh75UfjY2cZK8oII2GtRLCBxPz/1wIzjxFwyQ0GQnKiF RLpdIJ9uNRP7eQZUSRjnjwF+JLR44rznVEzGt36RkwYlhBom3pWQI7RdYwxBUbFm gpc03yJGjIe8QzvsRdZM/8kAVCruoUb1wASZSnxMGbIz9Es4HcA3Ll+zVfRlaRZW JXei456eBTnPMP1XzNqxS/Bn57hZfssaBzaJAdAAQXEEMGYF29M= =3M4G -----END PGP SIGNATURE----- --2VcK7Ezgm4IMdfSa--