Should we stop distributing source tarballs?

[Ben Cooksley]

On Sat, Apr 6, 2024 at 1:43 AM Heiko Becker <heiko.becker at kde.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20240406/a4348df2/attachment-0001.htm>