[arch-general] Severity of Failed checksum for PKGBUILD

[Daniel Micay]

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.

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