guix and nix people, go ahead and take your victory lap; yall earned it
@technomancy is this something to do with the xz 5.6 backdoor thing?
@alilly yes; the attack was delivered using release tarballs, so anyone packaging from source (which should be everyone) would not have been affected
I love debian but there is a lot about their packaging process that made sense in the 1990s and has no place in today's world
@technomancy I think Guix uses release tarballs sometimes
@alilly wait whaaaaaat
oh no
@technomancy I know there's an origin function for a tarball from a URL with a specific hash
and yeah here's the (source) for xz:
(source (origin
(method url-fetch)
(uri (list (string-append "http://tukaani.org/xz/xz-" version
".tar.gz")
(string-append "http://multiprecision.org/guix/xz-"
version ".tar.gz")))
(sha256
(base32
"0z9056ydsy76ib5cl1z60jkcqgr0x12d3lw1p2qnlcwi1fgxlp7c"))))
it's moot in this case because Guix is on xz 5.2.8 but yeah.
@alilly oh god what on earth; why
I expected them to know better?
@technomancy you can also use a Git repository but it's packager's choice
@alilly but if the tooling exists to use the git repo, what would cause a packager to make the wrong choice when the right choice is presumably just as easy to make?
I mean, with Debian they have the excuse of "all of this was written in like 1997" but not guix
@technomancy @alilly My understanding is that the release tarball was easier to work with in some way because it needed less dependencies or something.
The details are unclear to me but I guess the release tarball came with some stuff pre-generated? (Which, uh, yeah)
