On Tue, May 08, 2018 at 11:38:01PM -0400, Eli Schwartz via arch-general wrote: > When you say "still", that implies that there was any sort of effort to > change that in the first place... Fair enough :) I thought it's a slow natural process... > - not any sort of security check at all, they're there for CRC purposes, > and using strong CRC is security theater because the maintainer > probably just blindly ran updpkgsums without checking anything at all > so they generated very strong fake hashes -- come back when you have > PGP[1] which is actually security In this case, even using gpg keys won't guarantee security because verifying a key via a side channel is not much easier than the hash. > - actively dangerous as people think strong checksums equals security, > which makes them trust the sources even when they shouldn't; like > security theater except used as a justification for the other extreme Yes, but see [1] and [2]. At least with SHA hashes we are not so vulnerable. [1] http://cryptography.hyperlink.cz/2004/otherformats.html [2] https://www.mathstat.dal.ca/~selinger/md5collision > - better than nothing, and therefore very useful since it ensures that > you at least rebuilt the same thing the maintainer did No really, see just above. That is an old link, probably now forging .tar.gz files got much easier. > - very much security, because obviously the maintainer verifies sources > out of band, and checksums are their way of telling us what the > canonical sources are If (s)he does, then there will be multiple hashes, from different sources, no? > As extensively discussed in several mailing list and forum threads, the > best way to get security which everyone agrees on is to encourage > upstream developers to PGP-sign their sources. I've done quite a bit of > work on the existing TODO[1] which we have for implementing better PGP > checks (and HTTPS for both privacy and TLS endpoint verification), in > addition to providing the patchset[2] for makepkg (available in git > master and awaiting the 5.1 release) which allows verifying git(1) > signed commits/tags. Thanks for your work! I didn't know about those links, will check them out. But ok, I see your point... Thanks, L. -- Leonid Isaev