Re: Should we stop distributing source tarballs?
On Mon, Apr 8, 2024 at 1:55 AM Marc Deop i Argemí wrote: > On Saturday, 6 April 2024 18:22:22 CEST Sven Brauch wrote: > > 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. > > No, it is not. > > The key is that the infrastructure creation needs to also be automated. > > Once you have the *bootstrap* , you can trust the automation because you > can > review and audit it ( to a certain degree, of course, there is nothing > bullet > proof). > > I have been surprised for years on how the KDE infrastructure is handled > (so > many things done manually) but as I am not _in_ I cannot really judge > because > I don't know all of the circumstances and context. > The trust issue has nothing to do with the infrastructure - problems such as the XZ compromise cannot be resolved with technological barriers. The solution to them is social measures. Having the infrastructure itself hold the key makes it more difficult to distinguish between the various maintainers publishing the build, and makes it more likely that someone evil is able to publish a build without anyone noticing, and also makes it easier for an evil-doer to tamper with tarballs that are sitting on our infrastructure. Keeping the key material segregated from the actual release infrastructure (the key being on the release managers system, and the release infrastructure being download.kde.org) protects against this. I appreciate you are trying to protect against evil maintainers/release managers tampering with tarball contents, however there are other ways of addressing that. > > Best regards > > Marc Cheers, Ben
Re: Should we stop distributing source tarballs?
On Saturday, 6 April 2024 18:22:22 CEST Sven Brauch wrote: > 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. No, it is not. The key is that the infrastructure creation needs to also be automated. Once you have the *bootstrap* , you can trust the automation because you can review and audit it ( to a certain degree, of course, there is nothing bullet proof). I have been surprised for years on how the KDE infrastructure is handled (so many things done manually) but as I am not _in_ I cannot really judge because I don't know all of the circumstances and context. Best regards Marc signature.asc Description: This is a digitally signed message part.
Re: Should we stop distributing source tarballs?
Hi from the peanut gallery, The xz tarball was only a (minor) part of the problem. A big part of the backdoor was entirely in git and would be probably also usable if something else would have been added. Also, this tight coupling to git makes me uneasy. I like git and it's one of the best things on earth, but architecturally speaking i do not think that this tight coupling is really good. Git helps with release management and that's good, still only relying on git is not something i would like very much. The advantage of tarballs are imho: * making it easier to transition to another repository software if needed/wanted * making it easier to use for tarball-centric software distributions * making it easier to use if you want to migrate the repository service * separates development and development/debugging releases from release engineering/management. To be honest, i can imagine that at some point, there is enough distro agnostic tooling that we do not need release/src tarballs any more, but IMHO that point of time is not there yet. Just my two cents, Dennis Am 03.04.24 um 18:34 schrieb Albert Vaca Cintora: 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
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
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?
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?
On Sat, Apr 6, 2024 at 4:23 AM Johannes Zarl-Zierl wrote: > Am Freitag, 5. April 2024, 13:45:35 CEST schrieb Carl Schwan: > > On Friday, April 5, 2024 12:04:28 PM CEST Albert Vaca Cintora wrote: > > > - 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. > > > > 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, ...). > > Signing with a KDE key could have some benefits, though. It's far easier > for > distros (or users) to check KDE software against a single, well known key. > > On could mitigate the downside that you mentioned by having the script > check > the tag signature against a keyring of trusted keys. > Please see https://invent.kde.org/sysadmin/release-keyring/ - our process for validating tarballs for release already includes ensuring the GPG signatures provided are included in that keyring. All modern releases of KDE software that come with a GPG signature whose key is not in that keyring should be rejected. Developers should also consider adding their keys to Gitlab at https://invent.kde.org/-/profile/gpg_keys Following this, your GPG key will be published at https://invent.kde.org/$username.gpg > > Cheers, > Johannes Cheers, Ben
Re: Should we stop distributing source tarballs?
On Sat, Apr 6, 2024 at 1:43 AM Heiko Becker wrote: > 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. > I would consider any tarball that contains modified files (ie. is not a one to one representation of the git tag it represents) to be invalid for the purposes of KDE project releases. Now that translations are synced into our Git repositories there is no reason why we should have differences. > > > - 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? > This is really the key issue at hand. If you look at the timeline in question, the malicious actor(s) in the XZ incident moved slowly, starting as a general contributor, accruing trust and eventually made their way up to getting maintainer access and the ability to make releases. Even with the various checks and balances we have in place around granting developer accounts, who gets permissions to update our websites, requiring people to go through tickets to publish releases on download.kde.org, etc. a similar kind of attack played out over a long enough period of time is still one that none of our technological protections would be able to stop - as people who have been long term contributors and have worked their way up to being a maintainer will tend to obtain the necessary permission or trust of those with permissions. Such attacks however will always fail when confronted with enough sunlight however, something that Linus' law of "with enough eyes all bugs are shallow" covers fairly well. To adequately protect ourselves we need to ensure that projects that only have 1 or 2 maintainers, as well as those that are "community maintained" are monitored (historically a function that kde-commits@ has filled). There is also something to be said that for larger projects such as ours (ie. the ones who are targets) that we should also be keeping an eye on the smaller libraries that we depend on - as while we may be too hard to attack it is much easier to attack those we depend on who don't have the same resources we do (which is basically what happened with XZ/OpenSSH). These would be projects with just one or two maintainers with fairly infrequent activity, and that are often located in a maintainers personal namespace on GitHub or Gitlab.com, or on personal hosting of their own. Examples of projects in this sort of space would be the likes of QtKeychain or kColorPicker (just picking two that immediately spring to mind), but there is no reason that shouldn't also cover non-Qt libraries. There are probably a couple of different options we could explore in this space as to how to best accomplish this. We should also consider whether it is acceptable for us to depend on any project that uses a build system that is either bespoke or not modern (ie. autotools, self-written bash scripts, etc) - as that was a significant contributor to how the XZ attack was able to be perpetrated. My vote would be that it is not acceptable and we should be strongly pushing any project that does not use a modern build system to migrate to one that is. > > Regards, > Heiko > Cheers, Ben
Re: Should we stop distributing source tarballs?
Am Freitag, 5. April 2024, 13:45:35 CEST schrieb Carl Schwan: > On Friday, April 5, 2024 12:04:28 PM CEST Albert Vaca Cintora wrote: > > - 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. > > 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, ...). Signing with a KDE key could have some benefits, though. It's far easier for distros (or users) to check KDE software against a single, well known key. On could mitigate the downside that you mentioned by having the script check the tag signature against a keyring of trusted keys. Cheers, Johannes signature.asc Description: This is a digitally signed message part.
Re: Should we stop distributing source tarballs?
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
Re: Should we stop distributing source tarballs?
On Friday, April 5, 2024 12:04:28 PM 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. I would argue that there should be no change at all. Adapting the versions and adding the version to the AppStream file should be done in a git commit and not done in the tarball. This is already done by everyone using releaseme and following the steps from https://community.kde.org/ReleasingSoftware > - 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. 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, ...). > - 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. > Sample config below: > > [user] > signingkey = > [commit] > gpgsign = true > [gpg] > format = ssh > [tag] > forceSignAnnotated = true +1 git tags are already signed for people following the releaseme workflow. Signing commits is also good and I encourage everyone to do it but I wouldn't make it a requirement as it increases the barrier to contribution for new contributors. signature.asc Description: This is a digitally signed message part.
Re: Should we stop distributing source tarballs?
On Freitag, 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. > - 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. We could easily add a new service for signing and publishing the tarballs to our CI/CD system. The necessary basic infrastructure has been added in the last few months as part of our migration from Binary Factory to GitLab. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Should we stop distributing source tarballs?
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. - 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. - 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. Sample config below: [user] signingkey = [commit] gpgsign = true [gpg] format = ssh [tag] forceSignAnnotated = true
Re: Should we stop distributing source tarballs?
On piatok 5. apríla 2024 9:04:14 CEST Tobias Leupold wrote: > Am 05.04.24 um 06:25 schrieb Juraj Oravec: > > 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. > > If all commits in the xz repo would have been signed, the backdoor > would have been sneaked in as well -- only that the commit would have > been signed. Also if the tags would have been signed, the releases > with the backdoor would have been published exactly as is -- only > difference: The respective tags would have been signed. > > Just sayin ... You are correct, it would not solve a problem of corrupted tarballs. I am saying this for the "git tag" approach proposed in the first mail. How do we ensure that the repository was not tempered with by third party along the way by lets say governments or network companies? The governments wants (and in some states they already do) install a root certificates into your machines so that they can interfere in the encrypted https traffic. If the commits or at least tags are not signed, it makes it easy for them (in the name of safety) to redirect the packager or user to different server with tempered repository. Noone will suspect anything since there is no mechanism to make sure it is authentic. Other than hard working honest developers, nothing can protect us from the xz type of attack. Juraj signature.asc Description: This is a digitally signed message part.
Re: Should we stop distributing source tarballs?
Am 05.04.24 um 06:25 schrieb 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. If all commits in the xz repo would have been signed, the backdoor would have been sneaked in as well -- only that the commit would have been signed. Also if the tags would have been signed, the releases with the backdoor would have been published exactly as is -- only difference: The respective tags would have been signed. Just sayin ... 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
Re: Should we stop distributing source tarballs?
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 signature.asc Description: This is a digitally signed message part.
Re: Should we stop distributing source tarballs?
On Thursday 4 April 2024 04:26:57 PDT Sune Vuorela wrote: > 'does it use autotools?' The outcome of this is "please migrate off Autotools". -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Cloud Engineering
Re: Should we stop distributing source tarballs?
On Thursday, 4 April 2024 13:26:57 CEST, Sune Vuorela wrote: On 2024-04-04, Ben Cooksley wrote: I do also think it is nice if we get someone else to verify that the tarball we ship actually matches the tag. I think some people in distributions have already started looking into verifying that. Hopefully they'll be gentle with tooling that does this? I have only seen 'starting to look into it', not actually yet figuring out what to do with it. But as an approximation, I would expect 'does the tarball content match the tag?' 'can we easily and automatically explain the difference?' 'does it use autotools?' 'can autogenerated docs and stuff be moved to build time instead?' and other such things that might flag it differently and probably for manual inspections. I think we have stopped injecting translations at tarball creation time and our tarballs should actually match the git tags? Yes, that would be my expectation as well, tarballs should be identical to a checked out tag (minus the .git dir).
Re: Should we stop distributing source tarballs?
On Thursday, 4 April 2024 13:07:42 CEST, Ben Cooksley wrote: [snip] As an additional aside - we don't currently GPG sign our Git tags, so there is nothing validating that the person who made the release is actually the person whose name is on it. With GPG signatures we can at least validate who owns the key. We *do* sign the tags for KF, Plasma and Gear. And IIRC releasme defaults to signing tags as well. Regards, Heiko
Re: Should we stop distributing source tarballs?
Neal Gompa 于 2024年4月4日周四 22:19写道： > > That's fair, but they are not permanent and can be reaped when they're > not referenced by anything anymore. > If you pull these release commits in a "download" server and restrict write access to it, not giving everyone permission to delete a tag, just like what you do with the tarball download server, then it's the same. >
Re: Should we stop distributing source tarballs?
On Thu, Apr 4, 2024 at 10:18 AM Jin Liu wrote: > > > Neal Gompa 于 2024年4月4日周四 22:09写道： > > and because Git has no immutability > guarantees, it's not exactly ideal as an input either. > > Commits and trees in git are immutable. Refs like tags and branches are not. That's fair, but they are not permanent and can be reaped when they're not referenced by anything anymore. And it's still a pain to deal with anyway. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Should we stop distributing source tarballs?
Neal Gompa 于 2024年4月4日周四 22:09写道： > and because Git has no immutability guarantees, it's not exactly ideal as an input either. Commits and trees in git are immutable. Refs like tags and branches are not.
Re: Should we stop distributing source tarballs?
On Thu, Apr 4, 2024 at 9:52 AM Harald Sitter wrote: > > On Thu, Apr 4, 2024 at 3:38 PM Tobias Leupold wrote: > > > > Am 04.04.24 um 13:25 schrieb Harald Sitter: > > > On Thu, Apr 4, 2024 at 12:57 PM Tobias Leupold wrote: > > >> Just what comes into my mind at once. A release is not always only a git > > >> tag. > > > > > > Doesn't that make your source tarball a derived work from the source > > > in your git tag? > > > > Yes, of course! this was the point of what I wrote ... > > But then it's no longer **the** source. The source was your tag. A lot of distributions can't really easily consume Git as a source for software for packaging, and because Git has no immutability guarantees, it's not exactly ideal as an input either. That said, some of the issues that came up with xz-utils compromise are things we can more easily mitigate. We can be more vigilant about CMake scripts and CMake modules. We should treat them at the same level as source code itself for code review if we don't already. Another thing to think about is maybe switching from xz compression to zstd compression, as the compression ratio is generally quite close to xz and decompression is significantly faster and cheaper than xz. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Should we stop distributing source tarballs?
On Thu, Apr 4, 2024 at 3:38 PM Tobias Leupold wrote: > > Am 04.04.24 um 13:25 schrieb Harald Sitter: > > On Thu, Apr 4, 2024 at 12:57 PM Tobias Leupold wrote: > >> Just what comes into my mind at once. A release is not always only a git > >> tag. > > > > Doesn't that make your source tarball a derived work from the source > > in your git tag? > > Yes, of course! this was the point of what I wrote ... But then it's no longer **the** source. The source was your tag.
Re: Should we stop distributing source tarballs?
Am 04.04.24 um 13:25 schrieb Harald Sitter: On Thu, Apr 4, 2024 at 12:57 PM Tobias Leupold wrote: Just what comes into my mind at once. A release is not always only a git tag. Doesn't that make your source tarball a derived work from the source in your git tag? Yes, of course! this was the point of what I wrote ...
Re: Should we stop distributing source tarballs?
The tree-id of a git commit is effectively a checksum of all files. So you can ask packagers to pull a specific commit and verify either commit-id or tree-id. No extra verification step needed. Sune Vuorela 于 2024年4月4日周四 17:48写道： > On 2024-04-03, Albert Vaca Cintora wrote: > > What's the advantage of providing tarballs? > > I do think there is an advantage in being able to verify that the soure > tarball is the same across distributions. Using a checksum on the > tarball is an easy way of doing it. Different git invocations for git > archive, different tar options and so on can create different checksums > for the same content. > > I do also think it is nice if we get someone else to verify that the > tarball we ship actually matches the tag. I think some people in > distributions have already started looking into verifying that. > > Also, git tags can be moved. > > /Sune > >
Re: Should we stop distributing source tarballs?
On 2024-04-04, Ben Cooksley wrote: >> I do also think it is nice if we get someone else to verify that the >> tarball we ship actually matches the tag. I think some people in >> distributions have already started looking into verifying that. >> > > Hopefully they'll be gentle with tooling that does this? I have only seen 'starting to look into it', not actually yet figuring out what to do with it. But as an approximation, I would expect 'does the tarball content match the tag?' 'can we easily and automatically explain the difference?' 'does it use autotools?' 'can autogenerated docs and stuff be moved to build time instead?' and other such things that might flag it differently and probably for manual inspections. I think we have stopped injecting translations at tarball creation time and our tarballs should actually match the git tags? /Sune
Re: Should we stop distributing source tarballs?
On Thu, Apr 4, 2024 at 12:57 PM Tobias Leupold wrote: > Just what comes into my mind at once. A release is not always only a git tag. Doesn't that make your source tarball a derived work from the source in your git tag?
Re: Should we stop distributing source tarballs?
On Thu, Apr 4, 2024 at 10:48 PM Sune Vuorela wrote: > On 2024-04-03, Albert Vaca Cintora wrote: > > What's the advantage of providing tarballs? > > I do think there is an advantage in being able to verify that the soure > tarball is the same across distributions. Using a checksum on the > tarball is an easy way of doing it. Different git invocations for git > archive, different tar options and so on can create different checksums > for the same content. > For those wondering, for all content served by download.kde.org and files.kde.org, you can fetch a sha256 hash of the file in question by just appending ".sha256" to the URL in question. See https://download.kde.org/stable/release-service/24.02.1/src/okular-24.02.1.tar.xz.sha256 for instance. These won't show up in the file listings, and are not files that are provided to mirrors - they are provided by our mirror management system (MIrrorbits) directly. As an additional aside - we don't currently GPG sign our Git tags, so there is nothing validating that the person who made the release is actually the person whose name is on it. With GPG signatures we can at least validate who owns the key. > > I do also think it is nice if we get someone else to verify that the > tarball we ship actually matches the tag. I think some people in > distributions have already started looking into verifying that. > Hopefully they'll be gentle with tooling that does this? > > Also, git tags can be moved. > > /Sune > > Cheers, Ben
Re: Should we stop distributing source tarballs?
E-Mail von Albert Vaca Cintora vom Mittwoch, 3. April 2024, 18:34:04 CEST: > 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 Hi, I'm for sure nobody of importance here, but when you demand stopping releasing tarballs because some compression tool has been compromised you could as well demand to shut down all SSL servers because of the heartbleed bug or whatever. Just speaking of me, I not only release tarballs for KDE software, but also for other projects. There, I do the following more than for KDE: A release tarball is not necessarily one exact tag. Some (re)source files may be altered whilst preparing the release, some other stuff may be compiled from different repos or sources. E.g. for the documentation of one of my other projects, I use a @DATE@ placeholder that is finally replaced by the actual release date by a release script, and translated from RST to HTML for the final release tarball. I often e.g. also use a version.h.in header file and let cmake generate the real version.h when compiling. When releasing, I remove it and replace it by a version.h file containing the very version of this release -- which does not exist in git at all. Just what comes into my mind at once. A release is not always only a git tag. Also, git tags can be moved, deleted, created again and so on. When you do a release tarball, one can create checksums, sign it and so on. And even if the git repo is deleted, the sources are moved to another CVS or whatever at some point in the future: The tarball still exists. Also, one should think a bit more comprehensive here: Why should thousands of users create the same sources package over and over again if you can create it once, compress it and simply deliver it? This would be a waste of resources and energy, cause unneeded server load and so on. So, from my point of view the answer here is: No, we definitely should not stop to distribute source tarballs. Cheers, Tobias
Re: Should we stop distributing source tarballs?
On 2024-04-03, Albert Vaca Cintora wrote: > What's the advantage of providing tarballs? I do think there is an advantage in being able to verify that the soure tarball is the same across distributions. Using a checksum on the tarball is an easy way of doing it. Different git invocations for git archive, different tar options and so on can create different checksums for the same content. I do also think it is nice if we get someone else to verify that the tarball we ship actually matches the tag. I think some people in distributions have already started looking into verifying that. Also, git tags can be moved. /Sune
Should we stop distributing source tarballs?
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
