[gentoo-dev] cdrom.eclass vs KEYWORDS

[gentoo-dev] cdrom.eclass vs KEYWORDS

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]

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.

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=cdinstall on the rest.

WDYT?

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] cdrom.eclass vs KEYWORDS

[Mike Gilbert]

On Wed, Sep 25, 2019 at 4:14 PM Michał Górny <mgorny@gentoo.org> 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=cdinstall on the rest.
>
> WDYT?

Move them to an overlay.

Re: [gentoo-dev] cdrom.eclass vs KEYWORDS

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 2863 bytes --]

On Wed, Sep 25, 2019 at 10:14:36PM +0200, Michał Górny 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.
It's not live in that the content on the optical media does not change.

It is a gap in checksums, but I argue that this making a mountain out of
molehill. 

- The last NEW package using cdrom.eclass was added in 2017.
- The packages that use CDROM_ROOT are barely touched: because the
  source media is incredibly stable! No new releases, no upstream
  mucking with files. Several of the cases where it is touched were to
  support non-CDROM methods via downloaded files instead, which ARE
  covered by regular distfile checking.

> 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 specific problem you have here is a dependency on recursive copying,
rather than explicitly specifying each file: combined with the checksum
problem, gets you mystery files installed into somewhere (hopefully a
dedicated directory somewhere)

> 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.
This needs some minor amendments to the Manifest2 protocol I feel:
1. A distfile may have multiple different VALID checksums.
2. A distfile may not be ready for checksum validation until the ebuild has
   done some processing (e.g. load a CD) maybe a "MANUALDIST" type.

That problem statement has come up before, esp when upstreams have
rolled over distfiles for trivial reasons (forcing some users to
redownload the distfile if they had the old one already).

> So maybe the most obvious solution would be to remove KEYWORDS from
> ebuilds unconditionally using cdrom.eclass (and their reverse
> dependencies), and mask USE=cdinstall on the rest.
We should find who has copies of each of the media, and try to track
that for maintenance purposes as well.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

Re: [gentoo-dev] cdrom.eclass vs KEYWORDS

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

On Wed, 2019-09-25 at 21:30 +0000, Robin H. Johnson wrote:
> > So maybe the most obvious solution would be to remove KEYWORDS from
> > ebuilds unconditionally using cdrom.eclass (and their reverse
> > dependencies), and mask USE=cdinstall on the rest.
> We should find who has copies of each of the media, and try to track
> that for maintenance purposes as well.

Oh, yes, that's another problem as well.  Maybe games with cdinstall
should have dedicated maintainers rather than generic games@.  Though
the truth is, I suspect nobody has CDs for most of the games anymore.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] cdrom.eclass vs KEYWORDS

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 2679 bytes --]

On Wed, 25 Sep 2019 22:14:36 +0200
Michał Górny <mgorny@gentoo.org> 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.

Let's be realistic. If the CDs being used are pirated copies of dubious
origin then you deserve what you get. We're otherwise talking a
read-only medium that's generally been pressed in a factory. In the
highly unlikely event that there is malware present, it would probably
be for ancient versions of Windows or even MS-DOS. We usually only copy
off the data files anyhow. I have never seen any ebuilds for games that
run under Wine. I have considered adding some for games that run under
DOSBox but that is effectively sandboxed.

> 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.

When CDs were popular, different variants sometimes resulted in strange
bugs where it was not initially obvious what the cause was. Knowing
exactly what CD we're dealing with would be useful but on the other
hand, you'd probably have to read the whole CD for it to be effective,
which would take ages and may cause issues due to scratches and such.

> So maybe the most obvious solution would be to remove KEYWORDS from
> ebuilds unconditionally using cdrom.eclass (and their reverse
> dependencies), and mask USE=cdinstall on the rest.

Certainly only the unconditional case because the conditional case
would be a pain. In addition to what I've said above, you have to weigh
this up against the miniscule number of people who actually use them
these days, though I guess that could be taken as for or against. I
still like to support them but even I have many of the same games on
GOG now. As you know, I'd like to have GOG better supported but that's
another story.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]