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 4E47A138334 for ; Wed, 25 Sep 2019 21:35:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 61AF5E093E; Wed, 25 Sep 2019 21:35:24 +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 B4D90E093A for ; Wed, 25 Sep 2019 21:35:23 +0000 (UTC) Received: from symphony.aura-online.co.uk (154.189.187.81.in-addr.arpa [81.187.189.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: chewi) by smtp.gentoo.org (Postfix) with ESMTPSA id 2C37C34B59B for ; Wed, 25 Sep 2019 21:35:21 +0000 (UTC) Date: Wed, 25 Sep 2019 22:35:10 +0100 From: James Le Cuirot To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] cdrom.eclass vs KEYWORDS Message-ID: <20190925223510.6ec3f298@symphony.aura-online.co.uk> In-Reply-To: <9ac267ff85238b13b6943f67ab37f21a33898849.camel@gentoo.org> References: <9ac267ff85238b13b6943f67ab37f21a33898849.camel@gentoo.org> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) 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; boundary="Sig_/r7Ml9GUrul/PKM_mVC=elWb"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Archives-Salt: 3debcc53-624f-460c-8696-003e9b8c4d73 X-Archives-Hash: 84da1e624b48dca732986720f88253f8 --Sig_/r7Ml9GUrul/PKM_mVC=elWb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 25 Sep 2019 22:14:36 +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. >=20 > 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. Let's be realistic. If the CDs being used are pirated copies of dubious origin then you deserve what you get. We're otherwise talking a read-only medium that's generally been pressed in a factory. In the highly unlikely event that there is malware present, it would probably be for ancient versions of Windows or even MS-DOS. We usually only copy off the data files anyhow. I have never seen any ebuilds for games that run under Wine. I have considered adding some for games that run under DOSBox but that is effectively sandboxed. > 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. When CDs were popular, different variants sometimes resulted in strange bugs where it was not initially obvious what the cause was. Knowing exactly what CD we're dealing with would be useful but on the other hand, you'd probably have to read the whole CD for it to be effective, which would take ages and may cause issues due to scratches and such. > 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. Certainly only the unconditional case because the conditional case would be a pain. In addition to what I've said above, you have to weigh this up against the miniscule number of people who actually use them these days, though I guess that could be taken as for or against. I still like to support them but even I have many of the same games on GOG now. As you know, I'd like to have GOG better supported but that's another story. --=20 James Le Cuirot (chewi) Gentoo Linux Developer --Sig_/r7Ml9GUrul/PKM_mVC=elWb Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEPxcZ3tkwcedKm2a8EiZBXQDdMTcFAl2L3Y4ACgkQEiZBXQDd MTcChg//Q7qjHlYNiixsN8/Yqbgtottk+hnhmu0JVXTJXuBTleWTY+ns8asZ1hYR FEDaXnBuzxDJe3j3eP9VaofjX1KIfz81N8wwyjpnTyX8s289a67wTr1ZaphsrmtO rum8QBG9dcjB0e4fxF5IYQdUZoFRUHC2bB94xa+IdmsmfuFG6lWobPYwzu6Mi1wi oT+s/2kZdik/L5Dma50D7/YMfZPylS4kytogO0Uuh0kq6uZQ0jNwz1HMySP+OJB8 D4po7qmiAWZOaoLnmc+aMpDI347A04nsDxiOotraeCZXFEjM897QWOMBVYTpxA8k 2YHJgprm3nZLcaWEsKebU/90ad7StQpBXtXW1VrsDyojrCVBeo2/Ey8ZwcqN74RU vsSmYh8IktxKkD2uYfOoqmqW8OnL/ZHl/1VT6n+5Y6ck9vM+cGcxuYQrOQHNWgJa VThfD2SSGLqS5tgxgFkT8WFn3DDtdyviTDhwVHySVSVdUCc8MED9TkMxSCGGxhy/ j4/8R4Kk7S1C+CeymXccQXbqn4Mgto7lyuSeEJ8Dof9kiytjWrrLsMysVUdA5xfU zM4ymwij+TpO2h9NiMooMKp0hZq2Yxitk8TGNsfr5raZkQuWDYK73kDBZj8eqylz f/ykiAKs60i+22eFIMIOiGHKNf52IrMErBeNXmKGtzrCBxUf/7M= =dOFs -----END PGP SIGNATURE----- --Sig_/r7Ml9GUrul/PKM_mVC=elWb--