Should we stop distributing source tarballs?

[Ben Cooksley]

On Mon, Apr 8, 2024 at 1:55 AM Marc Deop i Argemí <kde at marcdeop.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20240408/e8b3fe11/attachment.htm>