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@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