On 2025-07-08, Denis 'GNUtoo' Carikli wrote: > Background: > ----------- > If we look at guix packages in various distributions, we have Guix > 1.4.0, 1.3.0 and 1.2.0[1]. > > For 1.3.0 we only have Ubuntu 22.04 and Trisquel 11, and the Trisquel > maintainer did a lot of work to update Guix from 1.3.0 to 1.4.0 but > this is not published yet as I understand. > > Debian has both 1.4.0 and 1.2.0 and as I understand, many distributions > rely on Debian as the upstream for security fixes.
Oh my, I totally forgot about 1.2.0! That *might* be out of security support for debian proper, but in theory the Debian LTS/ELTS projects might "support" it. I think the difference in the daemon between 1.2.0 and 1.4.0 was quite small, as I was generally able to apply relevent security patches with little to no changes, so if we get a working 1.4.0 branch, it would not be hard to further backport to 1.2.0 and even 1.3.0. > But the Debian package maintainer has the almost impossible task to > backport all the security fixes without a community nor help > behind[2][3] and as things are going, this will probably lead to the > Debian guix package being removed[2][3] with cascading effect for the > other distributions. If guix is truely a rolling release, it might not make much sense to maintain distribution packages of it. Up till recently, it has always been possible to backport changes with relative ease, but that was perhaps just lack of development... the recent unprivledged daemon stuff really made backporting patches harder. Also, with previous security updates, guix included a reproducer that we could use to test, and I did not see that in the announcement... (but have not read up on the CVEs and whatnot in detail) > Progress and questions: > ----------------------- > Given the current status I gave a quick and dirty try at "backporting" > the patches and so far I have something that compiles and I will try to > test it soon[4], but it most likely requires way more work to be > something acceptable for distributions as I did it in the quickest way > possible by applying all the patches (~50) that touch the daemon between > 1.4.0 and the last known security fix. I'm also not sure to find the > time to continue working on that. Yeah, I tried this too, but it failed to compile, so curious what your patchset looks like and how your progress on that has gone... will have to take a look at them. In the Debian release model, ideally we would avoid bringing in unrelated patchsets (e.g. the unprivledged daemon code bringing in an entire network stack?) but that might be too hard to pull off. Not sure if the security team would accept a patchset that includes more than the minimum necessary to fix the security issues. > The problem is also that I'm unsure how to collaborate on that. For > instance would it be possible to have some 1.4.0 branch where we could > send patches? This way it would make it easier for distributions to > collaborate, especially the less well known ones (no one will probably > look at Parabola for patches). Yeah, if we had some folks working on a 1.4.0.x branch with backported patches applied that would make continuing to support Guix packaged in Debian feasible. Without that, I think I would be inclined to recommend dropping the Guix package in Debian and just using the binary tarballs... The other option would be to not include guix in any Debian releases, and just provide updated packages via Debian backports, although this is generally frowned upon, and I am not sure I have enough enthusiasm to keep that going alone. :/ > In the case of Debian for instance, some of the patches depend on > having a debian/ directory, so it's not ideal for downstreams that > are not Debian derivatives. Not sure what you mean, the patches are shipped in a debian/ directory, but not truely dependent on there being a debian/ directory. But a git branch with all the appropriate patches applied would be better for everyone, for sure. > So having some upstream could simplify things, especially if at the end > all it takes to get security fixes is to just increment a minor number > corresponding to a git tag and rebuild the package. I like the idea, for sure! > Manual: > ------- > Also I think that the pull request 927[3] that adds information in > the manual on how to workaround the slow or lack of security updates > from distributions is complementary. > > Even if we get a 1.4.0 branch and that we do manage to backport fixes > correctly, it won't make it easier to update guix 1.3.0 and as I > remember seeing some user complain that Ubuntu 22.04 didn't fix the > security issues in the Guix 1.3.0 package, but I can't find it anymore. Probably true. Thanks for taking the initiative with this! Having other people looking into it and working together really helps! I have to admit the security announcement with no meaningful heads up really took the wind out of my sails, and I have had little energy to even look at it... which has left many Debian (and downstream) users vulnerable, which feels ... not great. Not great at all. Let us turn it around and improve the situation together! :) live well, vagrant
signature.asc
Description: PGP signature
