Re: Should we stop distributing source tarballs?
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.
Re: Should we stop distributing source tarballs?
Hi, On 06.04.24 13:07, Marc Deop i Argemí wrote: 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. This is basically a discussion about whether it is less risky to trust the individual developers, or the people with access to the CI signing key. You are trading likeliness of there being one bad actor vs. impact one bad actor can have. It's a matter of personal opinion; there is no right or wrong choice here. Whenever one option goes wrong, it will be easy to argue for changing to the other, until that one goes wrong, at which point you can change back. ;) IMO the only actual improvement here would be reproducible tarballing: if each run of the packaging script produces the same result on all systems, the maintainers can locally build the tarball, sign the hash, upload the signature, then have the CI system build the same tarball and sign it again. Then KDE publishes both signatures and downstreams check them both. I don't know how hard that would be to achieve technically, several obstacles come to mind immediately. But it would actually increase trust instead of just moving it around. Greetings, Sven OpenPGP_0xA4AAD0019BE03F15.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Should we stop distributing source tarballs?
Am Samstag, 6. April 2024, 18:22:22 CEST schrieb Sven Brauch: > Hi, > > On 06.04.24 13:07, Marc Deop i Argemí wrote: > > > 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. > > > This is basically a discussion about whether it is less risky to trust > the individual developers, or the people with access to the CI signing > key. You are trading likeliness of there being one bad actor vs. impact > one bad actor can have. It's a matter of personal opinion; there is no > right or wrong choice here. > > Whenever one option goes wrong, it will be easy to argue for changing to > the other, until that one goes wrong, at which point you can change back. > ;) > IMO the only actual improvement here would be reproducible tarballing: > if each run of the packaging script produces the same result on all > systems, the maintainers can locally build the tarball, sign the hash, > upload the signature, then have the CI system build the same tarball and > sign it again. Then KDE publishes both signatures and downstreams check > them both. > > I don't know how hard that would be to achieve technically, several > obstacles come to mind immediately. But it would actually increase trust > instead of just moving it around. > > Greetings, > Sven Hi Sven and all, you're totally right about the fact that you can trust an individual dev packaging a release on a local machine as much or as less as somebody running the infrastructure on the other side. I personally am all with Carl: I also would like to continue creating release tarballs on my local machine. None of all those technical dodges, may they be crafty as can be, would have prevented the backdoor which was the initial ignition of this whole discussion. Don't get me wrong. I'm all for signing release tarballs. If you want, we can also create signed tags if you think we need them. I also see that it's meaningful that such a release tarball contains the exact code of a tag. But we currently create checksums and PGP signatures for release tarballs, all created by a script. Which already makes the whole process completely reproducible. The tarball is the very code you get if you check out the tag. A distributor could check out the tag and compare the tarball with the resulting code. I only want to say we should ponder which real benefit any change will actually bring. Please don't make contributing to KDE harder than it has to be. Cheers, Tobias
