Am 05.12.2016 um 21:50 schrieb Eli Schwartz via arch-general:
On 12/05/2016 02:56 PM, sivmu wrote:
Am 04.12.2016 um 05:37 schrieb Maxwell Anselm via arch-general:
You mean the source files that you downloaded and then hashed...
Yes. If the source files are being modified via a MITM attack (which is trivial if the host uses HTTP) the checksum is still useful.
The checksum that was created by zou after downloading the compromised source file.
I don't see how that is useful. The checksum will always be correct and validate nothing
Possibilities
1) MITM attack between end-user and internet. PKGBUILD is downloaded over HTTPS, but source files are downloaded over HTTP. MITM attack cannot manipulate the PKGBUILD, but can fake the sources.
AUR maintainer was probably not under the same MITM. ;)
Why apply this only to AUR? The same is true for the regular repositories, but in that case you only need to MITM the maintainer and the checksums will not help. But yes for AUR this can help.
2) Source website hacked. AUR maintainer blindly generates checksums from the compromised source, nothing else matters because everyone is screwed.
Except if pgp signatures are provided by upstream und used in the PKGBUILD
3) Source website hacked, after the AUR maintainer generates checksums from the original uncompromised source.
This use case is valid.
...
In cases #1 & #3 (and #3 is only by accident) stronger checksums *will* help. Those are also the cases where it is more likely the maintainer is security-conscious and checks the sources before generating the manually-upgraded-to-sha256-or-higher checksums.
...
Context is everything. I am sure many people who read this thread are not aware of the following forum thread in which the matter was extensively discussed: https://bbs.archlinux.org/viewtopic.php?id=217588
Allan has already declared that he will not change the default makepkg.conf, on the grounds that #2 is the most likely scenario for people getting malicious packages. He also wants everyone to know that updpkgsums and makepkg are perfectly okay with maintainers changing the defaults, people who don't know there are defaults to change are probably not your best bet security-wise, and the only real security is either PGP or strong checksums posted by upstream on a second website. Also, that changing the defaults will encourage a false sense of security when people think that checksums have any validity in authentication.
Personally, I want the defaults changed because of #1 & #3, but it doesn't seem that will happen *as a matter of principle* so I guess everyone can continue bikeshedding here. Or in arch-dev-public. (Though having a TU take up the fight is indeed somewhat more useful than random users, so who knows?)
One valid reason to change the default checksum in general to a stronger algo, would be to prevent maintainer from using md5 as a security checksum. It is currently used for error detection during download. But using a strong hash is only really useful when there is a way to verify it. e.g. by pgp signatures or at least checksums on a https site. So if there is a way to verify upstream packages, using md5 inside PKGBUILD is bad. If there is no way to verify the upstream packages, using a stronger hash will provide a false sense of security. And thats what many seem to use it for. Thats partly why Allan won't change the default (if I understood him correctly) I my opinion, the way to solve this is to change the default md5 checksum to a different weaker one, preferably alias it to make sure it is understood as a error detection algorithmus. That way maintainers will understand that there is no verification of upstream packages by default and that they need to take care of that themselfs. The second change needed would be to strongly encourage maintainers to use pgp validation if available or to use strong checksum after getting packages over https. A LOT of packages do not use pgp validation even though upstream provides signatures. That is the real issue here. Let me say this again: everyone who is responsible for arch packages needs to be clearly advised to use all available methods to effectively verify upstream source files. Using a strong hash by default won't do that.