GNU bug report logs - #43075
Prioritize providing substitutes for security-critical packages with potentially long build times

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: "Mason Hock" <chaosmonk <at> riseup.net>
Cc: 43075 <at> debbugs.gnu.org
Subject: bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
Date: Fri, 11 Sep 2020 08:53:45 +0200

Hi,

"Mason Hock" <chaosmonk <at> riseup.net> skribis:

> On Thu Sep 10, 2020 at 1:00 AM PDT, Ludovic Courtès wrote:
>> Hi,
>>
>> chaosmonk <chaosmonk <at> riseup.net> skribis:
>>
>> > ungoogled-chromium receives frequent security updates, so it is
>> > important for users to keep it up-to-date.  However, binary
>> > substitutes for the latest version are usually not available, and it
>> > can take a  very long time to build from source, possibly multiple
>> > days on low-end hardware.  This might tempt or force some users to put
>> > off upgrading the package and run an older, vulnerable version until a
>> > binary substitute is available or they have a chance to set aside the
>> > uptime needed to build from source.
>> >
>> > I don't know what Guix's CI system looks like or how packages are
>> > queued for building, but if there is a way to prioritize builds for
>> > certain packages, I propose that substitutes for packages like
>> > ungoogled-chromium should be built as soon as possible once there is a
>> > new version.  Other security-critical packages with potentially long
>> > build times that come to mind are icecat and linux-libre.
>>
>> Thanks for your feedback. Our build farm has often been lagging behind
>> lately and that’s something we’ve been working on. The
>> ungoogled-chromium package is even more problematic because it takes
>> more than ~80 CPU-hours to build, and that often times out with our
>> current build farm settings (where we don’t allow builds to take more
>> than 6h, IIRC).
>
> Yes, Chromium's build time is obscene.  However, not providing
> substitutes for it duplicates that problem to the machines of every Guix
> user who uses ungoogled-chromium.  In the time that it would take Guix's
> build farm to build u-c it could probably build many other packages, but
> users are in the exact same situation, so a substitute for u-c is likely
> more valuable to them than substitutes for those other packages.  If it
> is possible to override the 6h timeout value for individual packages, I
> think that it would be worth doing so for u-c, and perhaps for Icecat
> and Linux-libre as well.

Definitely, yes.  I just meant to explain why the build farm often lacks
u-c substitutes currently, but I agree it must be addressed.

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.