On Sat, Mar 30, 2024 at 9:38 AM Richard W.M. Jones <rjones(a)redhat.com> wrote:
I'm not pretending these will solve everything, but they should make
attacks a little harder in future.
Thanks for starting the discussion.
A well resourced supply chain attack is probably
not preventable (no matter how many eyes are
looking). That does not mean we should not try
to minimize the likelihood of future such attacks.
(3) We should have a "security path", like "critical
path".
.....
Should we have a higher level of attention to these packages? We
already have "critical path", but that's a broad category now. These
seem like they are "security path" packages, an intentionally small
subset associated with very secure services which are enabled by
default.
Obligatory xkcd:
https://xkcd.com/2347/
What I do think we should start with is look at the
list of dependencies in the list of whatever we
can agree are security critical packages (running
as root and opening network ports is always a
good start) and dependencies which are not
supported by a large-ish organization (even if
only informal), with a set of experienced
developers, and sufficiently funded to continue
support of the package, and has a good security
reporting and response process in place.
xz would not seem to meet that vague hand
waving criteria, and so it should either be
replaced with something else (if possible) or get
it (or in this case, likely its new team) resourced
to its level of importance in the ecosystem.
I expect, with a critical eye, other such projects
will be identified.
The response to Heartbleed was (among other
things), resourcing OpenSSL. If a decision is
made that xz needs to stay as part of the critical
chain, it needs to be resourced too (although, as
others have suggested, removing xz from that
chain may be a better choice).