[arch-general] Stronger Hashes for PKGBUILDs

[Leonid Isaev via arch-general]

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,

[NicoHood]

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

[Neven Sajko via arch-general]

I do agree that using md5 is absurd, but putting effort into using
sha-2 seems like a waste when Keccak and BLAKE2 are both faster and
more secure than the old hashes.

Regards,
Neven

[Neven Sajko via arch-general]

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.

[Leonid Isaev via arch-general]

Post by Neven Sajko via arch-general

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

Yes, md5 is almost as good these days as crc32... It is ok if the sources are
gpg-signed, but not on its own.

Cheers,

[Eli Schwartz via arch-general]

Post by Leonid Isaev via arch-general

Post by Neven Sajko via arch-general

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.

[Ralph Corderoy]

Hi Eli,

Post by Eli Schwartz via arch-general
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.

[Leonid Isaev via arch-general]

Post by Ralph Corderoy
Hi Eli,

Post by Eli Schwartz via arch-general
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,

[Eli Schwartz via arch-general]

Post by Leonid Isaev via arch-general

Post by Ralph Corderoy
Hi Eli,

Post by Eli Schwartz via arch-general
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...

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.

[Leonid Isaev via arch-general]

Post by Eli Schwartz via arch-general
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,

[Ralf Mardorf]

GPG is not complicated at all.

https://aur.archlinux.org/pkgbase/linux-rt/#comment-645504

SICR

[Leonid Isaev via arch-general]

[0] https://lists.archlinux.org/pipermail/arch-general/2016-December/042

Oops, this link should have been
https://lists.archlinux.org/pipermail/arch-general/2016-December/042700.html

[David C. Rankin]

This is honestly a much better use of everyone's time.

It is indeed a rare occurrence to see the uncommon common sense rear its
lonely head from time to time... but comforting.

[Guus Snijders via arch-general]

Op do 10 mei 2018 01:26 schreef Leonid Isaev via arch-general <

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

Which is (still) pretty much the point of these hashes. With pacman these
are *not* very important.

The hashes are there for a quick check if the download is complete.
Integrity is a job for PGP.



Mvg, Guus Snijders

[Leonid Isaev via arch-general]

[extra]
...

This list should also include "python-retrying". I should have grepped more
carefully, sigh...