On 2025-09-01, Simon Josefsson wrote: > Ouch, removal of guix from Debian would hurt.
Go ahead, rub salt in my wounds! :) > Was any of the discussion public? You are replying to a public bug about the issue. There was a little back and forth in private with the security team and myself, mostly just reminding me to come up with an action plan on the issue. There were a few threads on guix-devel discussing how to resolve the issue: https://lists.gnu.org/archive/html/guix-devel/2025-07/msg00098.html I specifically mentioned that it will likely be removed: https://lists.gnu.org/archive/html/guix-devel/2025-07/msg00207.html So a few folks have tried to make it work, but months later, we still do not have a meaningful way forward... I made the mistake of thinking an open release-critical bug (e.g. the CVE bug) would have blocked it from making it into trixie, but clearly I was mistaken on that. It should have never been released with trixie. > Is there any chance to find a compromise to keep the package? Can you backport the current CVE fixes in an acceptible way? > The current Debian packaging are based on releases, which causes some > problem. Another approach is to base it on recent git commits, which > ought to have security bugs fixed. It is very difficult to base it off git commits (I have done so occasionally on experimental, but it is a bit of a grueling error-prone process). It also leaves people in a lurch, because substitutes may not be kept available for arbitrary snapshot commits, so people may end up having to do world rebuilds just to "guix pull" up to the current versions. > Due to the nature of how Guix is > rolling maybe handling of Guix security in Debian could be an exception? > Instead of back-port things, just publish a new version with security > fixes. This would be similar to how we treat Firefox if I recall > correctly. Well, firefox releases, what, every 6 weeks and Has Long-Term-Support branches with backproted fixes... so that is hardly a meaningful comparison... but that aside... That still means we are *theoretically* 2-3 months out from the next upstream guix release, and meanwhile people using the packages are running a severely security vulnerable version of guix since June (well, since forever, but it is since June it was made public, I think the issue was embargoed for three months before that, and besides quiet vague, inactionable mumblings a few days before the issue was made public, there was no public information about it). > If it would help, I can offer cycles to co-maintain Guix in Debian. > Back-porting security fixes sounds really complicated and I'm not sure I > see the point of handling Guix like that. Well, backporting security patches is exactly what is needed, unless you or someone else can propose some concrete, working alternative... Would also need help maintaining all the guile-* dependencies, which are mostly just to support guix. And honestly, I think they way several of those are packaged, we need some way to systematically trigger binNMUs (e.g. zstd gets updated to a new upstream version, guile-zstd should be binNMUed)... which is a mess I have not yet figure out how to tackle. > Are there any use-cases of Guix via Debian that would break if we just > bumped to latest upstream version after a security problem? The main issue is, assuming that guix starts releasing as often as planned (which is still entirely unproven), waiting 6-12 months to fix critical security issues in Debian ... does not really fit the security assurances expected of packages in Debian stable releases. I think until upstream is releasing more often *AND* providing security fixes backported (or maybe just providing backproted security fixes), it does not make sense to package Guix in Debian stable releases, at least not as currently packaged. Decoupling guix-daemon from the rest of guix could also be an interesting path that might make the work easier, but I have not seen much interest in that coming from upstream, and I suspect the direction is likely moving towards tighter coupling. The premise of the current packaging relied on the guix daemon not changing much, as it is really the only part of guix still used after running guix pull (and the rest of the several hundreds of MB of installed files go essentially unused)... which... is a lot of infrastructure to maintain when the guix-installer.sh script upstream provides an alternate path forward and a way to throw away the un-used bits. That does not even include all the dependent packages, which each may be individually small and fairly easy to maintain (apart form the binNMU issues), but each one adds up, and new ones get added every year. As an alternative, it might be plausible to package the guix-installer.sh script, although that has a lot of the same problems (e.g. there is no trust path to the "latest" version and possible missing substitutes, and the signed version has even more vulnerabilities than the current Debian package as it has zero security fixes applied). I would have rather seen Guix continue to be maintained in Debian proper, but I think the disconnect between Debian's stable release model and a rolling release upstream makes for a lot of challenging tension. It is only a happy accident that the parts that mattered (guix-daemon) had not seen much development in recent years. I would be more than happy to be proven otherwise, but I think the best thing at the moment is to remove Guix from various Debian stable releases... live well, vagrant
signature.asc
Description: PGP signature
