1 |
On Wed, Sep 25, 2019 at 10:14:36PM +0200, Michał Górny wrote: |
2 |
> Hi, |
3 |
> |
4 |
> I'm wondering if we're doing the right things by adding KEYWORDS to |
5 |
> packages using cdrom.eclass. After all, it's somewhat similar to live |
6 |
> ebuilds. That is, data is fetched outside regular PM mechanisms (though |
7 |
> not implicitly through Internet, arguably) and it is not covered by any |
8 |
> checksums. |
9 |
It's not live in that the content on the optical media does not change. |
10 |
|
11 |
It is a gap in checksums, but I argue that this making a mountain out of |
12 |
molehill. |
13 |
|
14 |
- The last NEW package using cdrom.eclass was added in 2017. |
15 |
- The packages that use CDROM_ROOT are barely touched: because the |
16 |
source media is incredibly stable! No new releases, no upstream |
17 |
mucking with files. Several of the cases where it is touched were to |
18 |
support non-CDROM methods via downloaded files instead, which ARE |
19 |
covered by regular distfile checking. |
20 |
|
21 |
> This creates a somewhat gaping security hole to anyone using those |
22 |
> packages. After all, the ebuilds are going to happily install any |
23 |
> malware you might have on that CD without even thinking twice about it. |
24 |
> In fact, with construction of many ebuilds it is entirely plausible that |
25 |
> additional unexpected files may end up being installed. |
26 |
The specific problem you have here is a dependency on recursive copying, |
27 |
rather than explicitly specifying each file: combined with the checksum |
28 |
problem, gets you mystery files installed into somewhere (hopefully a |
29 |
dedicated directory somewhere) |
30 |
|
31 |
> To be honest, I don't think this is a problem that could be fixed. |
32 |
> Technically, we could add some kind of, say, b2sum lists to ebuilds |
33 |
> and verify installed files against them. However, the way I understand |
34 |
> we frequently aim to support different releases of the same product, |
35 |
> that may have wildly differing checksums. |
36 |
This needs some minor amendments to the Manifest2 protocol I feel: |
37 |
1. A distfile may have multiple different VALID checksums. |
38 |
2. A distfile may not be ready for checksum validation until the ebuild has |
39 |
done some processing (e.g. load a CD) maybe a "MANUALDIST" type. |
40 |
|
41 |
That problem statement has come up before, esp when upstreams have |
42 |
rolled over distfiles for trivial reasons (forcing some users to |
43 |
redownload the distfile if they had the old one already). |
44 |
|
45 |
> So maybe the most obvious solution would be to remove KEYWORDS from |
46 |
> ebuilds unconditionally using cdrom.eclass (and their reverse |
47 |
> dependencies), and mask USE=cdinstall on the rest. |
48 |
We should find who has copies of each of the media, and try to track |
49 |
that for maintenance purposes as well. |
50 |
|
51 |
-- |
52 |
Robin Hugh Johnson |
53 |
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer |
54 |
E-Mail : robbat2@g.o |
55 |
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 |
56 |
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 |