Hi all, On 4/11/24 06:49, Andreas Enge wrote: > Am Thu, Apr 11, 2024 at 02:56:24PM +0200 schrieb Ekaitz Zarraga: >> I think it's just better to >> obtain the exact same code that is easy to find > The exact same code as what? Actually I often wonder when looking for > a project and end up with a Github repository how I could distinguish > the "original" from its clones in a VCS. With the signature by the > known (this may also be a wrong assumption, admittedly) maintainer > there is at least some form of assurance of origin.
I think this assumption deserves a lot more scrutiny than it typically gets (this is a general statement not particular to your message; even the tails project gets this part of security wrong and they are generally diligent in their efforts). I find it difficult to download PGP keys with any degree of confidence. Often, I see a file with a signature and a key served by the same web page, all coming from the same server. PGP keys are only useful if the attacker compromised the information that the user is receiving from the web page (for example, by gaining control of the web server or compromising the HTTPS session). In the typical scenario I have encountered, the attacker would also replace the key and signature with ones that they generated themself. In short, I'm not sure that we actually get any value from checking the PGP signature for most projects. Either HTTPS is good enough or the attacker won. 99% of the time HTTPS is good enough (though it is notable that the remaining 1% has a disproportionate impact on the affected population). Some caveats: It's difficult for me to use web of trust effectively because I haven't met anyone who uses PGP keys IRL. I'm ultimately trusting my internet connection and servers which are either semi-centralized (there are not that many open keyservers, it's an oligopoly for lack of a better term) or have the problem described above. So maybe everyone else is using web of trust effectively and I don't know what I'm talking about. =) The key download could be compared to the "trust on first use" model that SSH uses. It's not clear to me how effective a simple text box saying "we rotated our keys so you need to re-download it!" would be, but I suspect that most people would download without a second thought. It might be interesting to add public keys and signature locations to package definitions and have Guix re-verify the signature when it downloads the source. This would provide more scrutiny when keys are rotated (because of the review process) and would prevent harm from the situation where the package author is re-downloading the key each time the software is updated. The review process also adds a significant layer of protection because an attacker would need to compromise the HTTPS session of the reviewer in addition to the original package author (assuming that the signature is re-checked by the reviewer; I'm not sure how often this happens in practice). In principle it should be difficult for an attacker to predict who will be reviewing which issue. However, if the pool of reviewers is small it would be easier for the attacker to predict this or just compromise all of the reviewers. Also, if there was some way for the attacker to launch a general attack on people working out of the Guix repository then the value of this protection becomes negligible. The above two paragraphs are somewhat at odds: if Guix has the public key baked in and knows where to download the signature, some reviewers might not double-check the key that they get from the website because Guix is doing it for them. On one hand, I generally think that automating security makes it worse because once it's automated there's a system of rules for attackers to manipulate. On the other hand, if we assume people aren't doing the things they need to then no amount of technical support will give us a secure system. How much is reasonable to expect of people? From my extremely biased perspective, it's difficult to say. >> and everybody is reading. > This is a steep claim! I agree that nobody reads generated files in > a release tarball, but I am not sure how many other files are actually > read. > > Andreas I would guess that the level of the protection is strongly correlated with the popularity of the project among developers who need to add features or fix bugs. I don't think anybody reads a source repository "cover to cover", but we rummage around in the code on an as-needed basis. It would probably be difficult to sneak something into core projects like glibc or gcc, but pretty easy to sneak something into "emojis-but-cooler.js". It would be better to have comprehensive audits of all the projects, but that's not something Guix can manage by itself. It could make it easier to free up resources for that task, but I digress. While it is hyperbolic to say that "with enough eyes, all bugs are shallow" there is a kernel of truth to it. There's a reason they hid the noticeably malicious macros in the release tarball. In solidarity, Skyler