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

On Wed, May 09, 2018 at 12:31:39AM -0400, Eli Schwartz via arch-general wrote:

PGP keys are also far more likely to appear in multiple independently verifiable locations, you can embed them in your DNS records, post them on your blog, github profile, keybase.io proofs utilizing DNS as well as social media linkages, email footer (and signed email history) to establish a difficult-to-falsify history, or simply follow the PGP web of trust.

It is all true. But... if I care to only do "makepkg -g >> PKGBUILD", then I'm unlikely to follow web of trust, and if I'm going to scout mailing lists for email footers, I will also scout debian, gentoo, alpine and fedora repos for different hashes. That was my only point, but we are mixing policy and technical issues. If hashes are supposed to mean that I'm building the same source as the maintainer, then using only md5sums negate this because the source can be silently swapped using existing libraries, and attackers don't even need to know mathematics behind md5 collisions... I agree that using strong hashes alone does not address security of source distribution, but neither does HTTPS for instance. At least, with sha-2 hashes, point #3 of your previous email makes sense. Thanks, -- Leonid Isaev

On Wed, May 09, 2018 at 09:30:51PM +0200, Neven Sajko wrote:

I would just like to note that SHA-2 hashes are inferior to Keccak and to BLAKE2. So better not to spend effort migrating to SHA-2.

Strength of various SHA hashes is a different topic. My only point was that relying on md5 these days is like having no hashes at all or using the source filename as a hash... And there should be no migration -- when a new version of a package is released or a rebuild happens, just update the *sums array. Cheers, -- Leonid Isaev

On 05/10/2018 01:25 AM, Leonid Isaev via arch-general wrote:

On Wed, May 09, 2018 at 09:30:51PM +0200, Neven Sajko wrote:

...

I would just like to note that SHA-2 hashes are inferior to Keccak and to BLAKE2. So better not to spend effort migrating to SHA-2.

Strength of various SHA hashes is a different topic. My only point was that relying on md5 these days is like having no hashes at all or using the source filename as a hash...

And there should be no migration -- when a new version of a package is released or a rebuild happens, just update the *sums array.

Cheers,

Hello Leonid Isaev, I really like you effort on stronger hashes. I totally aggree with you that we need those, if we can't have GPG signatures by the maintainers. Hashes just help in less usecases than GPG signatures, of course, but they do. Unfortunately I made the experience, that this discussion is useless here and you rather start helping with GPG signatures for every package. If you want to put effort into this topic, which I really appreciate, please directly go for GPG signatures, otherway it will be just a frustrating discussion for you, sadly. What I can recommend to you for this is to write to upstream projects who don't use GPG signatures yet. Explain them why its important and help them to improve their software release security. I made the experience that quite a lot of projects did not know about the importance of GPG or just never looked into it. Just a few refuse to use GPG, leave that for now. As additional support you can use the GPGit guides as well as the automated (same named) GPGit tool: https://github.com/NicoHood/gpgit It will help new users to understand GPG and provide them an easy to use tool to get started with GPG within a few minutes. Feedback for this is appreaciated. I wish you all good luck, dont hesitate to contact me further if you have any great ideas regarding GPG etc. ~Nico

On Thu, 10 May 2018 03:46:34 -0600, Leonid Isaev via arch-general wrote:

GPG is not complicated at all.

https://aur.archlinux.org/pkgbase/linux-rt/#comment-645504 SICR -- pacman -Q linux{,-rt{,-pussytoes,-securityink,-cornflower}}|cut -d\ -f2 4.16.7-1 4.16.7_rt1-1 4.14.34_rt27-1 4.14.29_rt25-1 4.14.28_rt23-1

The single most beneficial change would be adoption of The Update Framework, since it is resilient against all known issues with remote package management, regardless of pkg signers coming/going and whether HTTPS is used or not. It also has a nice protocol for handling key revocation.

On 13 May 2018 at 20:11, Neven Sajko wrote:

I do agree that using md5 is absurd, ...

To clarify, md5 *is* unsecure and is even slower or not significantly faster than hashes from the Keccak and BLAKE2 families; using signatures would be a plus but signatures are not an argument for md5.

On 05/13/2018 08:11 PM, Leonid Isaev via arch-general wrote:

On Sun, May 13, 2018 at 08:19:19PM +0200, Neven Sajko via arch-general wrote:

...

On 13 May 2018 at 20:11, Neven Sajko wrote:

...

I do agree that using md5 is absurd, ...

To clarify, md5 *is* unsecure and is even slower or not significantly faster than hashes from the Keccak and BLAKE2 families; using signatures would be a plus but signatures are not an argument for md5.

It is trivial to enable blake2 support in makepkg using b2sum(1) from the coreutils package. Currently, I only saw gentoo using it but I didn't do proper research on this...

Maybe you could ask the coreutils developers whatever happened to implementing Keccak checksumming tools. -- Eli Schwartz Bug Wrangler and Trusted User

On Mon, May 14, 2018 at 11:23:39AM +0100, Ralph Corderoy wrote:

Hi Eli,

...

Maybe you could ask the coreutils developers whatever happened to implementing Keccak checksumming tools.

SHA-3? Have you see https://www.imperialviolet.org/2017/05/31/skipsha3.html I've also seen suggestions that the Keccak team push Kangaroo Twelve these days over SHA-3 due to SHA-3's comparative slowness.

Of course, none of this is relevant for the present thread... Cheers, -- Leonid Isaev

On Mon, May 14, 2018 at 11:01:57AM -0400, Eli Schwartz via arch-general wrote:

We're currently in feature freeze for pacman 5.1

Anyone who hopes to have b2sum support in *future* versions of pacman, would be well advised to come across as a person seeking to extend support for the current crop of common hashing algorithms, not someone pushing b2sum because "secure all PKGBUILDs".

For this reason, it would probably be useful to see coreutils support more than one cherry-picked modern hashing algorithm. I'm not really caring which ones those are, but then I'm also perfectly happy with sha256/sha512 (which are both of them great algorithms which work perfectly fine).

So I'm uninterested in the bikeshed on general principle, and only vaguely interested inasmuch as having more tools and more diversity in the future would probably be interesting and/or useful. But I can find lots of arguments for and against all the SHA3 candidates, some of them rather bitter, so I see no reason to take sides.

I agree... But I think that trying to identify the best algorithm is a waste of time because the only important feature is whether a given hash algorithm has been broken (in the sense of generating collisions). Everything else (performance, hash size, etc) is completely irrelevant for makepkg use... It would make sense to include B2B/SHA3 support in makepkg when we start seeing updtreams provide these hashes. Currently, AFAIK the only "upstream" doing that is Gentoo in their Manifests. Cheers, -- Leonid Isaev