[pacman-dev] [PATCH 2/2] makepkg: add new checksum algorithm via coreutils b2sum

[Eli Schwartz]

On 2/20/19 11:30 PM, Allan McRae wrote:
> On 16/2/19 2:38 am, Eli Schwartz wrote:
>> coreutils 8.26 in December 2016 added this new hashing method which is
>> compatible with the existing md5sum and sha*sum tool usage, while using
>> the blake2 hash algorithm.
>>
>> makepkg uses coreutils to provide source file integrity checks via
>> ${integ}sum binaries and it makes sense to offer this as an additional
>> option.
>>
>> Signed-off-by: Eli Schwartz <eschwartz at archlinux.org>
>> ---
> 
> Is there many open-source projects providing b2 checksums for their
> source files?

I haven't done much investigation, since I'd like makepkg to support it
either way, and, supporting it in makepkg can only be beneficial if
trying to convince upstreams to add them.
(This is independent of the fact that some aspects of the community,
myself included, believe in the value of Trust-On-First-Use for
packaging purposes, and/or would use b2sum if available, when releasing
our own software.)

However, I do know of at least one case where upstream provides b2sum.

For some background context: the Gentoo distribution has (as of November
2017) standardized on BLAKE2B plus SHA512 for verifying package sources,
and all new commits to their ebuild repository require both of these.

Gentoo is also the upstream for some projects, the one I am thinking of
specifically is [community]/pax-utils.

It is therefore possible to grab sha512sums=(...) b2sums=(...) from the
Gentoo ebuild, and additionally verify these using the PGP signature
upon the commit which added the ebuild and the source manifest for that
version of pax-utils. Note that the Gentoo package maintainer and the
lead developer are the same person.

So, implementing b2sum support in makepkg would mean that our pax-utils
packager could add upstream b2sum hashes as soon as the next version of
pacman is released.

> My opinion with checksums remains that they are only as good as the
> source you download them from.  If you have to generate them locally,
> they are already far from idea.  This is why md5sum will remain the
> default in pacman (unless we implement crc32...).

Didn't we conclude that crc32 is not even especially good at detecting
accidental errors? I think md5 is still a reasonable baseline here. :)

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20190221/b9dcf20c/attachment.sig>