Should we stop distributing source tarballs?

[Juraj Oravec]

On streda 3. apríla 2024 18:34:04 CEST Albert Vaca Cintora wrote:
> 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

Hello Albert,

The release tarballs can be signed with GPG (or is it PGP?) which 
provide another layer of protection to make sure the release is 
authenthic.

If KDE wants to lead by example and use only git tags for releases, at 
least the tags should be signed with GPG for verification.

It would be best to have all commits in the repository signed (in Gitlab 
"Verified"). While we are unable to make sure that the historical commits 
are also signed, since most of them are not, at least new commits and 
tags should be signed. Maybe the commits can be signed retrospectively 
(while breaking the repository history), but this is probablôy just my 
dream.

With modern approach for "reproducible" builds in the Linux 
distributions, it is required to provide a way to make sure that the 
release is authentic, the tarballs allows that, but with current use of 
git tags we do not even provide a way to make sure the tag was made by 
trusted developer or a release team, iinstead the tag could be faked by 
anyone providing another way of entry.

Have a nice day.
Juraj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20240405/9778dd32/attachment.sig>