Gentoo Archives: gentoo-dev

From: James Le Cuirot <chewi@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] cdrom.eclass vs KEYWORDS
Date: Wed, 25 Sep 2019 21:35:27
Message-Id: 20190925223510.6ec3f298@symphony.aura-online.co.uk
In Reply to: [gentoo-dev] cdrom.eclass vs KEYWORDS by "Michał Górny"
1 On Wed, 25 Sep 2019 22:14:36 +0200
2 Michał Górny <mgorny@g.o> wrote:
3
4 > Hi,
5 >
6 > I'm wondering if we're doing the right things by adding KEYWORDS to
7 > packages using cdrom.eclass. After all, it's somewhat similar to live
8 > ebuilds. That is, data is fetched outside regular PM mechanisms (though
9 > not implicitly through Internet, arguably) and it is not covered by any
10 > checksums.
11 >
12 > This creates a somewhat gaping security hole to anyone using those
13 > packages. After all, the ebuilds are going to happily install any
14 > malware you might have on that CD without even thinking twice about it.
15 > In fact, with construction of many ebuilds it is entirely plausible that
16 > additional unexpected files may end up being installed.
17
18 Let's be realistic. If the CDs being used are pirated copies of dubious
19 origin then you deserve what you get. We're otherwise talking a
20 read-only medium that's generally been pressed in a factory. In the
21 highly unlikely event that there is malware present, it would probably
22 be for ancient versions of Windows or even MS-DOS. We usually only copy
23 off the data files anyhow. I have never seen any ebuilds for games that
24 run under Wine. I have considered adding some for games that run under
25 DOSBox but that is effectively sandboxed.
26
27 > To be honest, I don't think this is a problem that could be fixed.
28 > Technically, we could add some kind of, say, b2sum lists to ebuilds
29 > and verify installed files against them. However, the way I understand
30 > we frequently aim to support different releases of the same product,
31 > that may have wildly differing checksums.
32
33 When CDs were popular, different variants sometimes resulted in strange
34 bugs where it was not initially obvious what the cause was. Knowing
35 exactly what CD we're dealing with would be useful but on the other
36 hand, you'd probably have to read the whole CD for it to be effective,
37 which would take ages and may cause issues due to scratches and such.
38
39 > So maybe the most obvious solution would be to remove KEYWORDS from
40 > ebuilds unconditionally using cdrom.eclass (and their reverse
41 > dependencies), and mask USE=cdinstall on the rest.
42
43 Certainly only the unconditional case because the conditional case
44 would be a pain. In addition to what I've said above, you have to weigh
45 this up against the miniscule number of people who actually use them
46 these days, though I guess that could be taken as for or against. I
47 still like to support them but even I have many of the same games on
48 GOG now. As you know, I'd like to have GOG better supported but that's
49 another story.
50
51 --
52 James Le Cuirot (chewi)
53 Gentoo Linux Developer