[arch-general] Stronger Hashes for PKGBUILDs
Leonid Isaev
leonid.isaev at jila.colorado.edu
Wed May 9 03:53:34 UTC 2018
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
More information about the arch-general
mailing list