[arch-general] Severity of Failed checksum for PKGBUILD

[Daniel Micay]

On 20/02/15 09:53 AM, Mark Lee wrote:
> On 02/20/2015 09:22 AM, Daniel Micay wrote:
>> On 20/02/15 09:03 AM, Mark Lee wrote:
>>>
>>> The checksums are there for integrity. The GPG signatures only
>>> confirm the packager built the package. My question is if a
>>> packager's PKGBUILD fails a checksum and the license is GPL, how
>>> does the packager fullfill their requirement to provide the
>>> source code? How does the packager prove that the source was used
>>> to build the binaries, especially when there are hash collisions
>>> in md5? The packager seems to offset the source code necessities
>>> by grabbing the source from upstream, but the checksums don't
>>> match...
> 
>> The checksums don't "prove" anything. A package could have simply
>> been built with --nocheck, it may have been built with a corrupt
>> source (it does nothing for the initial and most important
>> download) or upstream may have swapped out the tarball as they
>> often do.
> 
>> Complying with the GPL may mean making source packages available...
>> but the checksums really have nothing to do with it. You cannot
>> possibly reconstruct the sources from a checksum if the upstream
>> download goes away... it has no relevance to the GPL.
> 
>>> 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 aren't sources, they are a method of verifying the integrity
> of sources. In other words, while different files can have the same
> md5sum (hash collision), a failed checksum indicates something has
> definitely changed in the package. Checksums can have false positives
> but not false negatives.

I'm well aware of what cryptographic hashes are. A failed validation of
the sources indicates that the sources are different from what the
packager specified in the PKGBUILD, which could mean that the download
was corrupt or that something malevolent happened but in all likelihood
it simply means that upstream clobbered the tarball.

> In other words, the provided source is definitely not the same as the
> source the packager used (metadata difference in this case). If
> checksums are as useless as you claim, why even offer them if they
> cannot be reproduced for certain packages?

Again, checksums prove nothing. If the packager wants to build the
binary package with different sources, they can do that without the
checksums in the PKGBUILD reflecting it. The packager can ask makepkg
not to verify the checksums, and they could simply modify makepkg to
remove the check if there was no switch to turn it off... it in no way
avoids placing trust in the packager.

> Do packagers really just ignore checksums and "blindly update" on
> every release?

Yes, what else do you expect them to do? They run `updpkgsums` which
downloads the sources and updates the checksums... it has no security
value for the packages in the repositories. Zero. Value.

If upstream cares about security, they sign their releases. There is
fantastic support for verifying GPG signatures in makepkg, and we use it
whenever it's available. File a bug if a package could be using it and
is not using it.

Either way, you trust the packagers of binary packages. It is difficult
to verify that trust... the only way it is easy to do is if the build is
deterministic and the version of the packages used to build it is
specified. Since Arch's toolchain is rolling, reproducing builds is
going to be quite hard...

-------------- 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/64c5fd07/attachment.asc>