[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#43075: Prioritize providing substitutes for security-critical packag
From: |
Dr. Arne Babenhauserheide |
Subject: |
bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times |
Date: |
Fri, 11 Sep 2020 16:33:00 +0200 |
User-agent: |
mu4e 1.4.13; emacs 27.1 |
zimoun <zimon.toutoune@gmail.com> writes:
> On Fri, 11 Sep 2020 at 08:56, Ludovic Courtès <ludo@gnu.org> wrote:
>> To me the proposal is more about introducing scheduling priorities. For
>> these packages, it’s indeed safe to assume that every new release brings
>> security fixes.
>
> Why would some packages be prioritized on the build farm than others?
> Based on what? Which criteria?
There are two aspects that make ungoogled-chromium, icecat and
linux-libre special:
- long build time
- security critical
If a user cannot run the newest ungoogled-chromium, icecat, or
linux-libre due to too high build times (so it can for example only be
built on a weekend, but not on a weekday when the computer is only
active for a few hours), then this user is prone to be hit by zero-day
vulnerabilities.
So the minimal criterion would be: Protect users from zero-days.
For ungoogled-chromium, icecat, and linux-libre, two factors match:
- the chance is very high that an update fixes a vulnerability, and
- they take so long to build that many users won’t be able to do it
right away.
I certainly can’t: I cannot update ungoogled-chromium during work-time
because the compile is so heavy on resources, that it considerably slows
down my work.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
signature.asc
Description: PGP signature