Github releases use xz compression

[Pi-Cla]

@alerque Our github releases include tarballs that use xz compression.

Out of an abundance of caution (since our trust in the xz maintainers has been broken) we should remove them and no longer use xz. (I heard many people are using zst instead anyways)

https://archlinux.org/news/the-xz-package-has-been-backdoored/

[Pi-Cla]

Additionally I am having trouble building SILE with the .zip archive or the Source code .gz archive because of this:

[   37s] + ./configure --host=armv7hl-suse-linux-gnueabi --build=armv7hl-suse-linux-gnueabi --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-static --with-system-luarocks
[   37s] /var/tmp/rpm-tmp.Dp9tVR: line 44: ./configure: No such file or directory

[alerque]

Yes I'm aware. Busy recompiling things that are linked against it now, will look into artifacts later. Given the xz artifacts are reproducible and the scheme is known, I think we'll be able to prove that actual artifacts are not tainted, but I'll be reviewing that given time.

I prefer zstd when possible, but some platforms we support do not support it out of the box, hence I used xz as a compromise for compression vs. compatibility.

[Pi-Cla]

what's the current status on this?

[Omikhleia]

(I'm a bit off topic likely, but at the same time it seems the perfect place to remember, even if we are sometimes "pushy" on the maintainers of OSS we care about -- and it is good to care and push forward! --, we also have to support them in such situations, and to mitigate the pressure. Kudos and encouragements are important too.)

[alerque]

Lots more attention has come across the ecosystem and still no evidence of artifacts themselves being contaminated has surfaced. I'm not too worried about it. As such I'm not in a hurry to cut a new release just for this. Future releases will use ZSTD compression instead. Whether that is a v0.14.x patch release or v0.15.0 I'm not sure yet. I really need to hash out some final decisions and such and get 15 out, but the urgency is for publishing work I have that relies on it, not for XZ.

Also we build the manual using several fonts downloaded in XZ format. Lovely ;-)

[alerque]

For v0.14.18 (if it happens) we'll have artifacts as ZSTD instead of XZ. For v0.15.0 there are some extra macros that will get us checksums echoed in CI build logs and also attached to releases so that folks can verify the source archive attached to releases is actually the one generated in CI, not some later replacement by anybody (since GH doesn't surface an audit trail for those files). Then if you trust the Ubuntu host running in GH actions you can trust what you saw generated in logs there in a known 3rd party environment is actually the artifact you're downloading. GNU/Autotools has rough edges but this adds one small missing link in the transparency chain.