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 E3A79138334 for ; Wed, 25 Sep 2019 20:14:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 99FFAE0936; Wed, 25 Sep 2019 20:14:42 +0000 (UTC) Received: from smtp.gentoo.org (smtp.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 59655E0933 for ; Wed, 25 Sep 2019 20:14:42 +0000 (UTC) Received: from pomiot (c134-66.icpnet.pl [85.221.134.66]) (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 DF96134B5AA; Wed, 25 Sep 2019 20:14:40 +0000 (UTC) Message-ID: <9ac267ff85238b13b6943f67ab37f21a33898849.camel@gentoo.org> Subject: [gentoo-dev] cdrom.eclass vs KEYWORDS From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev Date: Wed, 25 Sep 2019 22:14:36 +0200 Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-Z5sFIla018bCoQYn8ztH" User-Agent: Evolution 3.32.4 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 X-Archives-Salt: 4d0d3532-09b6-49d6-b5ae-6865ca07b72b X-Archives-Hash: 269b50f6a89cafee0b6c4ee589c5b812 --=-Z5sFIla018bCoQYn8ztH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, 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. 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. 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. 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. WDYT? --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-Z5sFIla018bCoQYn8ztH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAl2LyqxfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM3 NkE4NDUwOTQwOThEMjhDQzhCMjZDNTYzOUFEQUUyMzI5RTI0MEUACgkQY5ra4jKe JA59xwgAx4FNx/1/0iXaDyWXIeH4YTsPPPvNaVG9XsSyYjQ7FkkdwTvJ41KH8Kpb lmIWJ4PZcOtq3oqJRZsntqSuPwH6/r9MSNRv/7XQSWc2kGGcSgNqkg6HJ1T6p8RI bVhaoWYp1IJ2ffv+mAvG2S7P2xtEbK846Wzt3Kil88oZsEEE71m/HQRzK2RUa47D LL3wl4m8MFkJPniRVfEFBNa2Cs2pFwt2Gfc7UDzBECdJBu8vkjG4EZcxACME03wj Lry9QYH2qHTgTgQll/TB7LyAHfLeUb7EIrpIvgAfFykUmpkeZI/GqbMYI+FVaphe af3qFyAGsMfUK7APHCZ2+h6Kc/wdUw== =HTZz -----END PGP SIGNATURE----- --=-Z5sFIla018bCoQYn8ztH--