[arch-general] Stronger Hashes for PKGBUILDs

[sivmu]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20161205/e2deb8d1/attachment-0001.asc>