[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 20 Nov 2019 18:49:15 +0100
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: Mitigating malicious packages in gnu/linux
On Wed, Nov 20, 2019 at 09:06:57AM -0800, Russ Allbery wrote:
> 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.
I fully agree.
Yet I think it's an option that people with a background and concerns
like Georgi's would want to at least consider. Not typical end-users.
Alexander
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.
