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 |