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