On 2025-12-18, Rostislav Svoboda wrote: >> I wished you would not call for abolishing this mechanism as a >> tangent to the discussion of whether there are rules relating to >> force pushing, especially when you choose not to acknowledge its >> major benefits. > > What we have here is an OS struggling with "Nobody wants to do code > reviews," running on HPCs of some national institutes involved in > military and security domains [1][2].
The fact that the vast majority of Guix packages successfully implement Reproducible Builds and Bootstrappable Builds helps allieviate some of the concerns about the institutions that host the infrastructure, although a more systematic review of the successes and failures would of course be welcome! > Now imagine secret services of unnamed adversarial governments > slipping in subtle backdoors over time, because all you need to get an > entry into .guix-authorizations is: > - place some 50 reviewed commits > - show some beneficial activity for 6 months > > What I call for is the abolition of a protection mechanism that fails > to protect us, only leading us into a false sense of security. What I hear you saying is "Because it is possible to (maliciously) convince people to give you a key, we should not bother to lock the door." The system in place is certainly imperfect, but it rasises the bar well beyond "compromise the forge itself or any forge account with commit access." That is not a false sense of security, unless you are expecting it to solve all your problems. It largely solves this one problem. It raises the bar to "steal or insert a compromised key into the web of trust merkle tree (as well as compromise the forge or forge account)" which is a different level and kind of compromise. > Again, it's not about who wrote the code - it's about what is in the code. Since anyone can review code, what is to prevent malicious reviews of the code? Who reviews the reviewers? And who reviews the reviewers who review the reviewers? etc. We live in a world of imperfections. Code can be written that is subtly broken that experts with extensive experience will fail to catch. Why bother reviewing code at all? Because it catches some problems... hopefully most problems. It would be a false sense of security to think that code review catches all problems. I do not advocate blind trust; trustworthy systems require little to no trust. As much as possible, we need to remove trust from our systems; we need to verify the end result as much as possible. (e.g. reproducible builds, bootstrappable builds, etc.) ... Guix is doing more of that than most other "similar" projects. Guix is relying on good faith efforts of a handful of volunteers to do the work that other distros have hundreds or even thousands of volunteers to do; commercial distros use thousands or even millions of paid employees. Guix does a lot with very little. Are there ways I would appreciate more rigor from others? Sure. If it is good enough... depends on your needs and interests. If it is not to your liking, by all means, propose real changes to improve it... I am skeptical of any suggestion that says drop imperfect thing X because imperfect thing Y is not happening enough. There are lots of approaches, and they are more often complimentary than competative! live well, vagrant
signature.asc
Description: PGP signature
