Should we stop distributing source tarballs?

[Marc Deop i Argemí]

On Friday, 5 April 2024 13:45:35 CEST Carl Schwan wrote:
> I disagree. I want my tarball to be signed with my GPG key stored in my
> Yubiky and not by a generic KDE key. It should be a proof that I as a
> maintainer of a project did the release and not someone else. Same with the
> upload to download.kde.org, while this adds some overhead in the process, I
> think it is important that KDE Sysadmins are the one who move the tarball
> to their final location and do some minimal check (checksum match, it's not
> a random person doing the release, ...).

I am sorry but that is *precisely* what we should not do.

The moment you are doing anything on your own without supervision or checks is 
the moment that you break the chain of trust.

If you automate things, everything can be reviewed/validated by more than one 
entity and thus increasing security.

The CI can be reviewed and audited but your personal laptop and your workflow 
cannot.

Some functionality that (I believe) is still not in the open source version of 
gitlab is the requirement of more than one reviewer for certain actions (MRs 
reviews come to mind).

Still, workaround for this missing functionality could be manually added to 
our workflows.

In addition, pushes to branches from where releases happen should be blocked 
by default. Of course, you need a way to bypass this for cases of emergency 
but for that logs of those actions should always be validated by a third 
entity (assuming the logs are pushed elsewhere, of course).

If anybody is interested in increasing our security, I recommend getting 
information about SLSA(Supply-chain Levels for Software Artifacts): https://
slsa.dev/spec/v1.0/

Best regards,

MArc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20240406/cd8af771/attachment.sig>