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

[Mason Hock]

On Thu Sep 10, 2020 at 1:00 AM PDT, Ludovic Courtès wrote:
> Hi,
>
> chaosmonk  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.

> Right now we’re trying to improve build throughput in general but your
> proposal makes sense, of course.
>
> Thanks,
> Ludo’.

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

[Mason Hock]

On Thu Sep 10, 2020 at 2:19 AM PDT, zimoun wrote:
> Hi,
>
> On Thu, 10 Sep 2020 at 10:01, Ludovic Courtès  wrote:
> > chaosmonk  skribis:
>
> > > 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.
>
> > Right now we’re trying to improve build throughput in general but your
> > proposal makes sense, of course.
>
> The recent updates of ungoogled-chromium do not mention [security
> updates].

Security fixes are generally provided upstream by the Chromium devs, so
the place to look for them is not ungoogled-chromium's changelog, but
Chrome/Chromium's changelog.[1]

> Well, I do not know if they are. So the question would be:
> what triggers the special security build?

For ungoogled-chromium, it is safe to assume that every new Chromium
release will contain security fixes.  I'm not sure about a general
solution that would work for other packages.  If Guix is tracking a
package's upstream VCS and upstream has a consistent commit message
format indicating security fixes, perhaps releases containing such
commits could trigger a security build.  Otherwise I'm not sure.

[1] 
https://chromereleases.googleblog.com/2020/08/stable-channel-update-for-desktop.html

> Well, the work-in-progress [1] about some metrics of Cuirass (Guix's
> CI) would provide interesting answers on the concrete feasibility and
> future improvements.
>
> [1] http://issues.guix.gnu.org/32548#1
>
>
> All the best,
> simon