> Might be easier overall to spend that effort on a hard switch to zstd > instead.
Good point. Another question that we'll probably have to ask anyway is, what is the future of xz-utils going to be now? Regarding its maintainership as well, both upstream and in Debian? >From what I understand, this package has been NMU'd in Debian for more than 10 years now - thanks to Sebastian for his work - and that might have been a point of weakness which was exploited to push a compromised version into the Debian archive, as seen in #1067708. To quote Thorsten from that thread: > Very much *not* a fan of NMUs doing large changes such as > new upstream versions. I can't say why exactly he would not be a fan, but with hindsight that was an interesting call. Perhaps more importantly, it is said that the whole situation started with the lack of resources from the upstream maintainer to maintain the project: https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html which again, we can suspect at this point, was exploited with the same modus operandi to get a compromise vector coopted in, in the form of a new maintainer. And now if what we suspect is true, that relief maintainer has turned out to be a bad actor, which leaves upstream back to square one on the maintainance issue. I understand that Lasse Collin hasn't been able to weigh in on the situation yet. Is xz-utils going to be maintained? Will we want to keep in the archive an unmaintained low-level library - low-level as in, susceptible of getting pulled as a dependency in lots of places - and rely on it for components such as dpkg? I'm not presuming the answers - it's still early and there is probably more to figure out yet - but back to the original point, we might want to consider this when sketching longer-term plans. -- Pierre Ynard
