Hi, 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. 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. As I understand, this would also make it harder for projects that use Guix and a forge for Q/A, because they typically use another distribution and 'apt install guix' to run tests (guix build -f guix.scm). Personally I also maintain a guix package in Parabola and so I have similar issues than Debian, and as part of GNU Boot, I also depend on Guix from Trisquel and/or PureOS, and in Trisquel the guix package was about to be removed at least in future Trisquel versions but I managed to convince the Trisquel maintainer to keep the guix package if it aligns with Debian. 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. 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). 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. 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. 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. But given the amount of work and that Ubuntu jammy is alone on that, and that there is probably less and less interest in Debian packages due to snap, we probably need to assume that this is the case even if I can't find this web page anymore. In addition backporting patches take time, and given the difficulty of doing that here, having a better way to collaborate doesn't mean that the patches will be backported before the announce of the vulnerabilities and that everybody will publish the packages and the announce and push the patches to the guix master branch at the same time. References: ----------- [1]https://repology.org/project/guix/versions [2]"I have no idea when or if I will be able to update the Guix package in Debian ... at this point I am leaning towards getting it removed from Debian, though I have put only minimal effort into trying to backport the patches..."[2] [3]https://codeberg.org/guix/guix/pulls/927 [4]https://codeberg.org/GNUtoo/guix-security-fixes.git Denis.
pgp6LVrszao0J.pgp
Description: OpenPGP digital signature
