Hi from the peanut gallery, The xz tarball was only a (minor) part of the problem. A big part of the backdoor was entirely in git and would be probably also usable if something else would have been added.
Also, this tight coupling to git makes me uneasy. I like git and it's one of the best things on earth, but architecturally speaking i do not think that this tight coupling is really good. Git helps with release management and that's good, still only relying on git is not something i would like very much. The advantage of tarballs are imho: * making it easier to transition to another repository software if needed/wanted * making it easier to use for tarball-centric software distributions * making it easier to use if you want to migrate the repository service * separates development and development/debugging releases from release engineering/management. To be honest, i can imagine that at some point, there is enough distro agnostic tooling that we do not need release/src tarballs any more, but IMHO that point of time is not there yet. Just my two cents, Dennis Am 03.04.24 um 18:34 schrieb Albert Vaca Cintora:
Hi KDE folks, The recent xz backdoor scandal made me realize how bad and obsolete distributing tarballs is. The source of truth for our code are the repositories, and releases can simply be tags on those repos. As a big free software community, I think we should lead by example and get rid of tarballs altogether (as I hope to see in other projects as well) after the recent events. Packagers can git pull. If we ever replace git with something else, that something else will have tags as well. What's the advantage of providing tarballs? Albert
