[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Should we stop distributing source =?iso-8859-1?Q?tarballs=3F?=
From:       Heiko Becker <heiko.becker () kde ! org>
Date:       2024-04-05 12:43:26
Message-ID: 01b14179-e0f2-4130-a19d-5617dc744781 () kde ! org
[Download RAW message or body]

On Friday, 5 April 2024 12:04:28 CEST, Albert Vaca Cintora wrote:
> It seems a lot of people feel conservative in favor of tarballs, so
> maybe I aimed too far. At least I think the discussion brought some
> interesting points that we can explore further. Some I identified:
>
> - The tarballs should contain no changes with respect to git, or
> minimal changes obviously justifiable in a diff.

Like I wrote earlier in this thread, this should hold true already since 
the translations are synced to git.

> - Tarballs should only be generated in a reproducible manner using
> scripts. Ideally by the CI only.
> - We should start to sign tarballs in the CI.

The scripts already exists for the bundles and users of releasme. Letting 
the CI create tarballs seems indeed like a good way to reduce possibilities 
of human tampering.
With regard to signing: At first I thought that it means something that the 
person responsible for the release is also signing the tarballs. But maybe 
there could even be two signatures in the future, one by CI and one by the 
release person (although that would probably mean a few challenges for the 
tooling).

> - We should start to sign commits and tags. Git recently made this
> super easy by allowing signing with the ssh keys that we all are
> already using to push things, so no excuses for not enabling this.

We already sign commits for the 3 release bundles and users of relaseme.

But I'm surprised about the total absence of social aspects of the xz 
incidence during this discussion.
Admittedly we fall back to community maintenance if a maintainer becomes 
unavailable, so the exact xz scenario doesn't seem likely. But there are 
probably a few projects on the fringes. Do we have safeguards in place if a 
nefarious person tries to steps up as maintainer? Can we do something to 
help projects, which are struggling?

Regards,
Heiko
[prev in list] [next in list] [prev in thread] [next in thread]