public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Subject: [gentoo-dev] cdrom.eclass vs KEYWORDS
Date: Wed, 25 Sep 2019 22:14:36 +0200	[thread overview]
Message-ID: <9ac267ff85238b13b6943f67ab37f21a33898849.camel@gentoo.org> (raw)

[-- 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 --]

             reply	other threads:[~2019-09-25 20:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-25 20:14 Michał Górny [this message]
2019-09-25 21:13 ` [gentoo-dev] cdrom.eclass vs KEYWORDS Mike Gilbert
2019-09-25 21:30 ` Robin H. Johnson
2019-09-26  4:08   ` Michał Górny
2019-09-25 21:35 ` James Le Cuirot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9ac267ff85238b13b6943f67ab37f21a33898849.camel@gentoo.org \
    --to=mgorny@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox