Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87wobumq8e.fsf@hope.eyrie.org>
Date: Wed, 20 Nov 2019 09:06:57 -0800
From: Russ Allbery <eagle@...ie.org>
To: oss-security@...ts.openwall.com
Subject: Re: Mitigating malicious packages in gnu/linux

Solar Designer <solar@...nwall.com> writes:

> Contrary to traditional best practices, update only what and when needs
> to be updated.  (Of course, you take responsibility to watch for any
> relevant security updates, or accept the risk if you neglect to do that.
> You also miss silent security fixes, but on the other hand you similarly
> miss newly introduced vulnerabilities.)

I'm very reluctant to give this advice, not because it's wrong, but
because the failure mode is misaligned for most people.

The average user of a distribution (personal or professional) is at much
greater risk of a compromise due to an unpatched security vulnerability
than due to malicious code introduced in the distribution package update
stream.  Both are *possible*, but one of them is far more common (I would
even say by orders of magnitude).  Determining which updates are security
updates is tedious and requires a lot of discipline; it's something that
humans are generally bad at, and the failure mode is usually to not apply
the update.  Many security updates are not explicitly flagged as such (see
all the recent discussions on this list about CVEs).

The average user is therefore best served by applying all distribution
updates.  Choosing not to update to reduce your risk of a supply chain
attack is a very advanced technique, and I would tell people to think very
hard about whether they want to sign up for the necessary cognitive load
and disciplined decision-making required to identify relevant security
updates that they need to apply.

-- 
Russ Allbery (eagle@...ie.org)             <https://www.eyrie.org/~eagle/>

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.