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
