--00000000000083176206159394e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 8, 2024 at 1:55=E2=80=AFAM Marc Deop i Argem=C3=AD 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 --00000000000083176206159394e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Apr 8, 2024 at 1:55=E2=80=AFAM Ma= rc Deop i Argem=C3=AD <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. impac= t
> one bad actor can have. It's a matter of personal opinion; there i= s 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 ca= n
review and audit it ( to a certain degree, of course, there is nothing bull= et
proof).

I have been surprised for years on how the KDE infrastructure is handled (s= o
many things done manually) but as I am not _in_ I cannot really judge becau= se
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 b= arriers.
The solution to them is social measures.

<= /div>
Having the infrastructure itself hold the key makes it more diffi= cult to distinguish between the various maintainers publishing the build, a= nd makes it more likely that someone evil is able to publish a build withou= t 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 infrastructu= re being download.kde.org) protects= against this.

I appreciate you are trying to prot= ect against evil maintainers/release managers tampering with tarball conten= ts, however there are other ways of addressing that.
=C2=A0
=

Best regards

Marc

Cheers,
Ben=C2=A0
--00000000000083176206159394e7--