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 235E8138334 for ; Wed, 25 Sep 2019 21:31:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6563FE08ED; Wed, 25 Sep 2019 21:31:03 +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 0BBDFE08DD for ; Wed, 25 Sep 2019 21:31:03 +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 BFEA334B5A2 for ; Wed, 25 Sep 2019 21:31:01 +0000 (UTC) Received: (qmail 25799 invoked by uid 10000); 25 Sep 2019 21:30:54 -0000 Date: Wed, 25 Sep 2019 21:30:54 +0000 From: "Robin H. Johnson" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] cdrom.eclass vs KEYWORDS Message-ID: References: <9ac267ff85238b13b6943f67ab37f21a33898849.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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UPT3ojh+0CqEDtpF" Content-Disposition: inline In-Reply-To: <9ac267ff85238b13b6943f67ab37f21a33898849.camel@gentoo.org> User-Agent: Mutt/1.12.1 (2019-06-15) X-Archives-Salt: df6abf31-2a00-4ea1-8a68-fccab9324e8c X-Archives-Hash: 969f34c916f26348be368a636d467880 --UPT3ojh+0CqEDtpF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 25, 2019 at 10:14:36PM +0200, Micha=C5=82 G=C3=B3rny wrote: > Hi, >=20 > I'm wondering if we're doing the right things by adding KEYWORDS to > packages using cdrom.eclass. After all, it's somewhat similar to live > ebuilds. That is, data is fetched outside regular PM mechanisms (though > not implicitly through Internet, arguably) and it is not covered by any > checksums. It's not live in that the content on the optical media does not change. It is a gap in checksums, but I argue that this making a mountain out of molehill.=20 - The last NEW package using cdrom.eclass was added in 2017. - The packages that use CDROM_ROOT are barely touched: because the source media is incredibly stable! No new releases, no upstream mucking with files. Several of the cases where it is touched were to support non-CDROM methods via downloaded files instead, which ARE covered by regular distfile checking. > This creates a somewhat gaping security hole to anyone using those > packages. After all, the ebuilds are going to happily install any > malware you might have on that CD without even thinking twice about it.= =20 > In fact, with construction of many ebuilds it is entirely plausible that > additional unexpected files may end up being installed. The specific problem you have here is a dependency on recursive copying, rather than explicitly specifying each file: combined with the checksum problem, gets you mystery files installed into somewhere (hopefully a dedicated directory somewhere) > To be honest, I don't think this is a problem that could be fixed.=20 > Technically, we could add some kind of, say, b2sum lists to ebuilds > and verify installed files against them. However, the way I understand > we frequently aim to support different releases of the same product, > that may have wildly differing checksums. This needs some minor amendments to the Manifest2 protocol I feel: 1. A distfile may have multiple different VALID checksums. 2. A distfile may not be ready for checksum validation until the ebuild has done some processing (e.g. load a CD) maybe a "MANUALDIST" type. That problem statement has come up before, esp when upstreams have rolled over distfiles for trivial reasons (forcing some users to redownload the distfile if they had the old one already). > So maybe the most obvious solution would be to remove KEYWORDS from > ebuilds unconditionally using cdrom.eclass (and their reverse > dependencies), and mask USE=3Dcdinstall on the rest. We should find who has copies of each of the media, and try to track that for maintenance purposes as well. --=20 Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robbat2@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 --UPT3ojh+0CqEDtpF Content-Type: application/pgp-signature; name="signature.asc" -----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. iQKTBAABCgB9FiEEveu2pS8Vb98xaNkRGTlfI8WIJsQFAl2L3IxfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEJE RUJCNkE1MkYxNTZGREYzMTY4RDkxMTE5Mzk1RjIzQzU4ODI2QzQACgkQGTlfI8WI JsTQGg/+L9SXoT+UcCpRzORVxFty8kitIkl7grpxnk1DEftjn7zv1BmWS6f+HZDw jeNsorXkn6c1OQaNYVEdsk6dk07My+XL2deYU2XjSdReRMnFOPWUthh5BpipK22n 6lLCv9i1nMJ3n9RiHqTcifPrxZP4nf09xns0668JwNW9hoek+btCybHH7L6H/5mB ZfoIXmDNWbxFUIRG+ORlNKw1nua3ICKUHAnxohy3iyF8839+NlwLJV9EqTMnEg7j Bt8e3qqsSEYQ+r14qDqG0qmJQTxyejmMrE+1hC7C2P8PnHUuFFWe3vs0US1uWjNb OYH5CDJzb/7NUEdayOAH2qRFz5gzS1PKY7BxCwuTmZ9ABt5O/9Po1Fbb3vzhwtO0 oJ5DMQYNatvvDCGMo0ubY6QCKpQxe0zZjkRIEpHGwnHTaL98CWE7+y9u8E1O+TXp BRjwsoMyLjTOlqvPxjFDxFff+wIBe+0KTqH37b7vvBgjnyF9+ii4P51QDl8pmdzO xjJwDVoYwk4AljkAk8NuFs/WZPuIlMu7UcOkt65Ms3eVsCSAtjEX37reouCcYA+g m3iLMIzKiD+w5AEy61xVdIimckkAskeRjNxBRnXdp4TSoakW3rnYWR8r1B6e7sOG 8yKMlLo8FTB2+NS1nuSLzr1vtC6nsf6eCE4ns51XKaEvsojTeFw= =DpEW -----END PGP SIGNATURE----- --UPT3ojh+0CqEDtpF--