| 1 |
On Wed, Sep 25, 2019 at 4:14 PM Michał Górny <mgorny@g.o> wrote: |
| 2 |
> |
| 3 |
> Hi, |
| 4 |
> |
| 5 |
> I'm wondering if we're doing the right things by adding KEYWORDS to |
| 6 |
> packages using cdrom.eclass. After all, it's somewhat similar to live |
| 7 |
> ebuilds. That is, data is fetched outside regular PM mechanisms (though |
| 8 |
> not implicitly through Internet, arguably) and it is not covered by any |
| 9 |
> checksums. |
| 10 |
> |
| 11 |
> This creates a somewhat gaping security hole to anyone using those |
| 12 |
> packages. After all, the ebuilds are going to happily install any |
| 13 |
> malware you might have on that CD without even thinking twice about it. |
| 14 |
> In fact, with construction of many ebuilds it is entirely plausible that |
| 15 |
> additional unexpected files may end up being installed. |
| 16 |
|
| 17 |
The eclass seems to be used exclusively by games (with one exception), |
| 18 |
which are probably full of unreported security problems anyway. |
| 19 |
|
| 20 |
> To be honest, I don't think this is a problem that could be fixed. |
| 21 |
> Technically, we could add some kind of, say, b2sum lists to ebuilds |
| 22 |
> and verify installed files against them. However, the way I understand |
| 23 |
> we frequently aim to support different releases of the same product, |
| 24 |
> that may have wildly differing checksums. |
| 25 |
> |
| 26 |
> So maybe the most obvious solution would be to remove KEYWORDS from |
| 27 |
> ebuilds unconditionally using cdrom.eclass (and their reverse |
| 28 |
> dependencies), and mask USE=cdinstall on the rest. |
| 29 |
> |
| 30 |
> WDYT? |
| 31 |
|
| 32 |
Move them to an overlay. |
Archives