[arch-general] Severity of Failed checksum for PKGBUILD

Daniel Micay danielmicay at gmail.com
Fri Feb 20 14:59:47 UTC 2015


On 20/02/15 09:41 AM, Florian Pelz wrote:
> Hi,
> 
> On 02/20/2015 03:22 PM, Daniel Micay wrote:
>> On 20/02/15 09:03 AM, Mark Lee wrote:
>>> I understand that the metadata changed which changed the checksum, but
>>> that doesn't really change the question of what to do with source code
>>> versioning systems that have changing checksums and the need to supply
>>> source code for GPL projects.
>>
>> Checksums aren't sources. Checksums aren't a proof that the package was
>> built from those sources. Checksums also aren't a valuable security
>> mechanism, unlike the support for GPG verification of sources. They're
>> blindly updated on every release and clobbering release is common... so
>> we've all learned to ignore checksum failures. I don't understand what
>> this has to do with the GPL.
>>
> 
> Checksums proof that the sources you downloaded when running makepkg are
> the same sources the author of the PKGBUILD used. This can be a valuable
> security measure when those sources are not downloaded on a secure
> connection (http instead of https and the like).

The checksums can only verify that you obtained the same sources as the
author of the PKGBUILD. Since upstreams clobber the old tarballs so
often, failure to validate doesn't mean much...

The vast majority of users make use of the binary packages and the
checksums do absolutely nothing to secure the main attack vector which
is a compromise of the sources downloaded by the packager. It is only
relevant to the tiny minority of people building a package with ABS.

The more meaningful compromise needs to happen to the actual package in
the repositories. A compromise of the server hosting the sources is the
most likely way for this to happen. HTTPS can't do anything to defend
against it. HTTPS can only defend against a MITM attack on a specific
downstream packager.

There is support for validating sources with GPG signatures, which is a
complete solution to this issue. If you care, then file issues for any
packages that aren't using the upstream signatures yet, and complain to
upstream if they aren't signing the releases.

> I'm not sure if downloads over the git:// protocol are actually
> verified, because the transfer is definitely not secure. I do hope so.

Git's read-only protocol is not authenticated. It supports SSH and HTTPS
which do have two different forms of authentication, both of which are
very flawed. Signed tags make a lot more sense, and you shouldn't be
using code from development branches if you care a lot about robustness
and security, since

-------------- 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/20150220/5a3dd608/attachment.asc>


More information about the arch-general mailing list