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
signature.asc
Description: This is a digitally signed message part.
