[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Should we stop distributing source tarballs?
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2024-04-08 10:50:44
Message-ID: CA+XidOHAmf7W+FGRhDN72Jc5RksPseOhWtnxJXRVpsguXjdQFA () mail ! gmail ! com
[Download RAW message or body]

On Mon, Apr 8, 2024 at 1:55 AM Marc Deop i Argemí <kde@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

[Attachment #3 (text/html)]

<div dir="ltr"><div dir="ltr">On Mon, Apr 8, 2024 at 1:55 AM Marc Deop i Argemí \
&lt;<a href="mailto:kde@marcdeop.com">kde@marcdeop.com</a>&gt; wrote:<br></div><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Saturday, 6 April \
2024 18:22:22 CEST Sven Brauch wrote:<br> &gt; This is basically a discussion about \
whether it is less risky to trust<br> &gt; the individual developers, or the people \
with access to the CI signing<br> &gt; key. You are trading likeliness of there being \
one bad actor vs. impact<br> &gt; one bad actor can have. It&#39;s a matter of \
personal opinion; there is no<br> &gt; right or wrong choice here.<br>
<br>
No, it is not.<br>
<br>
The key is that the infrastructure creation needs to also be automated. <br>
<br>
Once you have the *bootstrap* , you can trust the automation because you can <br>
review and audit it ( to a certain degree, of course, there is nothing bullet <br>
proof).<br>
<br>
I have been surprised for years on how the KDE infrastructure is handled (so <br>
many things done manually) but as I am not _in_ I cannot really judge because <br>
I don&#39;t know all of the circumstances and \
context.<br></blockquote><div><br></div><div>The trust issue has nothing to do with \
the infrastructure - problems such as the XZ compromise cannot be resolved with \
technological barriers.</div><div>The solution to them is social \
measures.</div><div><br></div><div>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.</div><div><br></div><div>Keeping the key \
material segregated from the actual release infrastructure (the key being on the \
release managers system, and the release infrastructure being <a \
href="http://download.kde.org">download.kde.org</a>) protects against \
this.</div><div><br></div><div>I appreciate you are trying to protect against evil \
maintainers/release managers tampering with tarball contents, however there are other \
ways of addressing that.</div><div>  </div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
Best regards<br>
<br>
Marc</blockquote><div><br></div><div>Cheers,</div><div>Ben  </div></div></div>



[prev in list] [next in list] [prev in thread] [next in thread]