On 20/02/15 12:54 PM, Florian Pelz wrote: > On 02/20/2015 04:51 PM, Daniel Micay wrote: >> PKGBUILD checksums provide *zero*, yes *zero* security for the case >> that matters most, which is the build done by the packager. It does >> provide the ability for other people to verify that a MITM attack >> was not used to target a specific packager... but that is far, far >> less likely than a compromise of the sources on the upstream server >> and it can't do anything about that. >> > > I guess the likelihood depends on who the attacker and what their > motive is, but you are probably right. Still, checksums improve > security in cases that can matter if there is no better verification > from upstream. > > That said, if the security is verified another way, is there no need > to use SHA256 rather than MD5, because the latter should be enough for > ensuring there are no download errors? Security is provided by signatures. The hashes don't provide security for the official packages, only an audit trail at best and only for detecting a MITM attack, not an upstream compromise. The hashes are also redundant in an --allsource package. >> Trust in certificate authorities is trust in many corporations and >> governments around the world. It's trust in tends of thousands of >> individuals with the ability to sign whatever they want. An >> attacker with the ability to perform a targeted MITM attack on a >> specific Arch developer likely has the ability to sign whatever >> they want. >> > > Any certificate authority caught signing fraudulent certificates would > no longer be trusted. They surely can, but they would not want to. > Unless you are an extremely high value target, I think CAs can be trusted. So why are Comodo and TurkTrust still trusted, among others? Anyway, they can get away with quite a lot before getting caught - if they ever are. I'm not sure why you would be worried about an extremely niche targeted attack on Arch Linux but not this.
Attachment:
signature.asc
Description: OpenPGP digital signature
