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 158B2138334 for ; Wed, 25 Sep 2019 21:14:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 26FEBE092D; Wed, 25 Sep 2019 21:13:59 +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 C68FDE0909 for ; Wed, 25 Sep 2019 21:13:57 +0000 (UTC) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: floppym) by smtp.gentoo.org (Postfix) with ESMTPSA id 591A934B5AB for ; Wed, 25 Sep 2019 21:13:56 +0000 (UTC) Received: by mail-io1-f45.google.com with SMTP id z19so782980ior.0 for ; Wed, 25 Sep 2019 14:13:56 -0700 (PDT) X-Gm-Message-State: APjAAAXkltGziXL+y5VbSPCNWtwILuA0+N3cn12C8tRWpWwl8APN74NM uGnAzy7S7W2c+t2itKCxjb26c12D9+sO/1oSRC0= X-Google-Smtp-Source: APXvYqyYKy8Teyc+AEci/o1DqGU89ec/DmDcdwBXvbRFr8vjZYZFgQtjdmfnDJvW7F1DAEFYLxggdRK3gNNRXzpg8GY= X-Received: by 2002:a02:cabb:: with SMTP id e27mr281822jap.107.1569446034251; Wed, 25 Sep 2019 14:13:54 -0700 (PDT) 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 References: <9ac267ff85238b13b6943f67ab37f21a33898849.camel@gentoo.org> In-Reply-To: <9ac267ff85238b13b6943f67ab37f21a33898849.camel@gentoo.org> From: Mike Gilbert Date: Wed, 25 Sep 2019 17:13:43 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [gentoo-dev] cdrom.eclass vs KEYWORDS To: Gentoo Dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 2b022157-6285-46d7-b321-95648b92a0d2 X-Archives-Hash: 5b4105f5962929dec209ae7484f33b54 On Wed, Sep 25, 2019 at 4:14 PM Micha=C5=82 G=C3=B3rny = wrote: > > 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. > In fact, with construction of many ebuilds it is entirely plausible that > additional unexpected files may end up being installed. The eclass seems to be used exclusively by games (with one exception), which are probably full of unreported security problems anyway. > To be honest, I don't think this is a problem that could be fixed. > 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? Move them to an overlay.