* bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
@ 2020-08-27 20:50 chaosmonk
2020-09-10 8:00 ` Ludovic Courtès
0 siblings, 1 reply; 13+ messages in thread
From: chaosmonk @ 2020-08-27 20:50 UTC (permalink / raw)
To: 43075
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
2020-08-27 20:50 bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times chaosmonk
@ 2020-09-10 8:00 ` Ludovic Courtès
2020-09-10 9:19 ` zimoun
2020-09-11 1:14 ` Mason Hock
0 siblings, 2 replies; 13+ messages in thread
From: Ludovic Courtès @ 2020-09-10 8:00 UTC (permalink / raw)
To: chaosmonk; +Cc: 43075
Hi,
chaosmonk <chaosmonk@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).
Right now we’re trying to improve build throughput in general but your
proposal makes sense, of course.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
2020-09-10 8:00 ` Ludovic Courtès
@ 2020-09-10 9:19 ` zimoun
2020-09-11 0:47 ` Bengt Richter
` (2 more replies)
2020-09-11 1:14 ` Mason Hock
1 sibling, 3 replies; 13+ messages in thread
From: zimoun @ 2020-09-10 9:19 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 43075, chaosmonk
Hi,
On Thu, 10 Sep 2020 at 10:01, Ludovic Courtès <ludo@gnu.org> wrote:
> chaosmonk <chaosmonk@riseup.net> 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]. Well, I do not know if they are. So the question would be:
what triggers the special security build?
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
2020-09-10 9:19 ` zimoun
@ 2020-09-11 0:47 ` Bengt Richter
2020-09-11 1:06 ` Mason Hock
2020-09-11 6:56 ` Ludovic Courtès
2 siblings, 0 replies; 13+ messages in thread
From: Bengt Richter @ 2020-09-11 0:47 UTC (permalink / raw)
To: zimoun; +Cc: chaosmonk, 43075
Hi,
On +2020-09-10 11:19:11 +0200, zimoun wrote:
> Hi,
>
> On Thu, 10 Sep 2020 at 10:01, Ludovic Courtès <ludo@gnu.org> wrote:
> > chaosmonk <chaosmonk@riseup.net> 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]. Well, I do not know if they are. So the question would be:
> what triggers the special security build?
>
> 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
>
>
>
Given
[1] https://www.theregister.com/2020/09/04/linux_kernel_flaw_detection/
I would guess that any publicly visible coding meant to trigger special prioritized
security builds would feed the process described in [1].
Maybe that's insignificant compared to scraping commit notes and patches etc, idk.
HTH :)
--
Regards,
Bengt Richter
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
2020-09-10 9:19 ` zimoun
2020-09-11 0:47 ` Bengt Richter
@ 2020-09-11 1:06 ` Mason Hock
2020-09-11 6:56 ` Ludovic Courtès
2 siblings, 0 replies; 13+ messages in thread
From: Mason Hock @ 2020-09-11 1:06 UTC (permalink / raw)
To: zimoun, Ludovic Courtès; +Cc: 43075
On Thu Sep 10, 2020 at 2:19 AM PDT, zimoun wrote:
> Hi,
>
> On Thu, 10 Sep 2020 at 10:01, Ludovic Courtès <ludo@gnu.org> wrote:
> > chaosmonk <chaosmonk@riseup.net> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
2020-09-10 8:00 ` Ludovic Courtès
2020-09-10 9:19 ` zimoun
@ 2020-09-11 1:14 ` Mason Hock
2020-09-11 6:53 ` Ludovic Courtès
1 sibling, 1 reply; 13+ messages in thread
From: Mason Hock @ 2020-09-11 1:14 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 43075
On Thu Sep 10, 2020 at 1:00 AM PDT, Ludovic Courtès wrote:
> Hi,
>
> chaosmonk <chaosmonk@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.
> Right now we’re trying to improve build throughput in general but your
> proposal makes sense, of course.
>
> Thanks,
> Ludo’.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
2020-09-11 1:14 ` Mason Hock
@ 2020-09-11 6:53 ` Ludovic Courtès
0 siblings, 0 replies; 13+ messages in thread
From: Ludovic Courtès @ 2020-09-11 6:53 UTC (permalink / raw)
To: Mason Hock; +Cc: 43075
Hi,
"Mason Hock" <chaosmonk@riseup.net> skribis:
> On Thu Sep 10, 2020 at 1:00 AM PDT, Ludovic Courtès wrote:
>> Hi,
>>
>> chaosmonk <chaosmonk@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’.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
2020-09-10 9:19 ` zimoun
2020-09-11 0:47 ` Bengt Richter
2020-09-11 1:06 ` Mason Hock
@ 2020-09-11 6:56 ` Ludovic Courtès
2020-09-11 7:37 ` zimoun
2 siblings, 1 reply; 13+ messages in thread
From: Ludovic Courtès @ 2020-09-11 6:56 UTC (permalink / raw)
To: zimoun; +Cc: 43075, chaosmonk
Hi,
zimoun <zimon.toutoune@gmail.com> skribis:
> On Thu, 10 Sep 2020 at 10:01, Ludovic Courtès <ludo@gnu.org> wrote:
>> chaosmonk <chaosmonk@riseup.net> 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]. Well, I do not know if they are. So the question would be:
> what triggers the special security build?
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.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
2020-09-11 6:56 ` Ludovic Courtès
@ 2020-09-11 7:37 ` zimoun
2020-09-11 8:23 ` Ricardo Wurmus
` (3 more replies)
0 siblings, 4 replies; 13+ messages in thread
From: zimoun @ 2020-09-11 7:37 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 43075, chaosmonk
Hi,
On Fri, 11 Sep 2020 at 08:56, Ludovic Courtès <ludo@gnu.org> wrote:
> > The recent updates of ungoogled-chromium do not mention [security
> > updates]. Well, I do not know if they are. So the question would be:
> > what triggers the special security build?
>
> 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?
Popularity? But we do not measure (yet?) how many times a substitute
is downloaded.
For example, I do not use ungoogled-chromium so I would prefer that
the resources of the build farm would be spent on these X packages.
Bob and Alice, they would prefer these Y packages. How do we reach a
consensus?
And security is one criteria. But how to detect it is a security fix?
(Aside the issue of ungoogled-chromium about the time limit you
described; which should be fixed, obviously. :-))
I understand the annoyance and the frustration of the substitutes
availability but I am not convinced that some packages have higher
priority on the substitute delivery than others.
All the best,
simon
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
2020-09-11 7:37 ` zimoun
@ 2020-09-11 8:23 ` Ricardo Wurmus
2020-09-11 13:39 ` Leo Famulari
` (2 subsequent siblings)
3 siblings, 0 replies; 13+ messages in thread
From: Ricardo Wurmus @ 2020-09-11 8:23 UTC (permalink / raw)
To: zimoun; +Cc: 43075, chaosmonk
zimoun <zimon.toutoune@gmail.com> writes:
> I understand the annoyance and the frustration of the substitutes
> availability but I am not convinced that some packages have higher
> priority on the substitute delivery than others.
Hard to say. I think this discussion is a little premature given our
historic underutilization of the build farm hardware, which is very
often idle. Perhaps once the instrumentation of Cuirass has yielded
actionable paths to improving this we can reconsider if priorization is
still necessary or even feasible.
--
Ricardo
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
2020-09-11 7:37 ` zimoun
2020-09-11 8:23 ` Ricardo Wurmus
@ 2020-09-11 13:39 ` Leo Famulari
2020-09-11 14:33 ` Dr. Arne Babenhauserheide
2020-09-11 14:45 ` Ludovic Courtès
3 siblings, 0 replies; 13+ messages in thread
From: Leo Famulari @ 2020-09-11 13:39 UTC (permalink / raw)
To: zimoun; +Cc: chaosmonk, 43075
[-- Attachment #1: Type: text/plain, Size: 750 bytes --]
On Fri, Sep 11, 2020 at 09:37:59AM +0200, zimoun wrote:
> I understand the annoyance and the frustration of the substitutes
> availability but I am not convinced that some packages have higher
> priority on the substitute delivery than others.
In general, I agree with you, especially since most packages do not
really take very long to build if there are no substitutes available, or
they do not change very often.
However, I noticed today that we do not have substitutes for linux-libre
5.4.64, which was released upstream and added to Guix two days ago. In
my experience, we have rarely required users to build linux-libre, and I
think the current situation is a serious regression for our build farm.
We should prioritize building the kernel.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
2020-09-11 7:37 ` zimoun
2020-09-11 8:23 ` Ricardo Wurmus
2020-09-11 13:39 ` Leo Famulari
@ 2020-09-11 14:33 ` Dr. Arne Babenhauserheide
2020-09-11 14:45 ` Ludovic Courtès
3 siblings, 0 replies; 13+ messages in thread
From: Dr. Arne Babenhauserheide @ 2020-09-11 14:33 UTC (permalink / raw)
To: zimoun; +Cc: 43075, chaosmonk
[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
2020-09-11 7:37 ` zimoun
` (2 preceding siblings ...)
2020-09-11 14:33 ` Dr. Arne Babenhauserheide
@ 2020-09-11 14:45 ` Ludovic Courtès
3 siblings, 0 replies; 13+ messages in thread
From: Ludovic Courtès @ 2020-09-11 14:45 UTC (permalink / raw)
To: zimoun; +Cc: 43075, chaosmonk
Hi,
zimoun <zimon.toutoune@gmail.com> skribis:
> On Fri, 11 Sep 2020 at 08:56, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> > The recent updates of ungoogled-chromium do not mention [security
>> > updates]. Well, I do not know if they are. So the question would be:
>> > what triggers the special security build?
>>
>> 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?
> Popularity? But we do not measure (yet?) how many times a substitute
> is downloaded.
> For example, I do not use ungoogled-chromium so I would prefer that
> the resources of the build farm would be spent on these X packages.
> Bob and Alice, they would prefer these Y packages. How do we reach a
> consensus?
> And security is one criteria. But how to detect it is a security fix?
>
> (Aside the issue of ungoogled-chromium about the time limit you
> described; which should be fixed, obviously. :-))
All we’re saying is that for some packages, we should always assume that
new releases bring security fixes. These are key packages like
Linux-libre, IceCat, ungoogled-chromium, etc.
Furthermore, ungoogled-chromium is practically not buildable on one’s
laptop, and thus it’s even more important to provide substitutes.
For now, the focus should be on improving overall build throughput since
there’s a lot of room for improvement.
Ludo’.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-09-11 14:46 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-08-27 20:50 bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times chaosmonk
2020-09-10 8:00 ` Ludovic Courtès
2020-09-10 9:19 ` zimoun
2020-09-11 0:47 ` Bengt Richter
2020-09-11 1:06 ` Mason Hock
2020-09-11 6:56 ` Ludovic Courtès
2020-09-11 7:37 ` zimoun
2020-09-11 8:23 ` Ricardo Wurmus
2020-09-11 13:39 ` Leo Famulari
2020-09-11 14:33 ` Dr. Arne Babenhauserheide
2020-09-11 14:45 ` Ludovic Courtès
2020-09-11 1:14 ` Mason Hock
2020-09-11 6:53 ` Ludovic Courtès
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.