* 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 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
* 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
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 public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).