[arch-general] Stronger Hashes for PKGBUILDs

[Eli Schwartz]

Okay, first things first -- what happened to replying in-thread with a
message-id linking together replies?

Oh right, you are once again using disposable, temporary Mailinator
email addresses (via their alternate domains).

Admin note: Please, someone add everything here to the invalid email
domains list, as this is getting annoying:
https://gist.github.com/nocturnalgeek/1b8fa44283314544c487

On 12/08/2016 12:20 PM, fnodeuser wrote:
> checksums and message digests are not the same thing.[1]
> 
> checksums are not suitable for integrity verification, and the best
> (meaning, at the time of writing and for the foreseeable future, most
> secure), currently supported cryptographic hash function algorithm
> (that is sha512 in AL's case), must be used to compute the message
> digests of the files.
> 
> message digests are one of the things that we can and must use for
> security. not all upstreams have https enabled and not all of them
> sign their files with gpg.

Sure they're the same. It is the same underlying technology, used for
the same purposes (and not just by Arch).

> it was because of me that the 'Use gpg signatures and https sources'
> task was added to the todo list.[2][3][4]

Thanks, I guess. Although I cannot help but notice you were rather
aggressive about it. Can't you raise these concerns in a slightly more
polite manner?

> these things must be checked by the users also, not only by the
> package maintainers. i check everything, most of you check nothing.
> you just do 'pacman -Syu'.

Um, what? `pacman -Syu` does, in fact, check that every package is
signed by a Developer or Trusted User whose key is in archlinux-keyring.

I can hope for the day when the repo database will be signed as well (to
avoid malicious mirror "downgrade"/vulnerability-freezing attacks), but
in the meantime I am still pretty secure.

Unless, of course, you are suggesting that I should have no faith in the
honesty of the Arch Linux Devs/TUs.

> let us start with firefox's PKGBUILD file for the first example. you
> are using sha256mds instead of sha512mds. you can see at 
> https://ftp.mozilla.org/pub/firefox/releases/50.0.2/, that there are
> 3 files, KEY, SHA512SUMS, and SHA512SUMS.asc. that is one example
> where you are using a smaller digest size than upstream, that cannot
> be verified with the signature. another example is nmap's PKGBUILD
> file. you continued to use sha1mds instead of sha512mds.[5]

sha256sums is plenty secure enough. So I assume the Firefox maintainer
uses that mega-file to validate the download, then uses updpkgsums to
update the current sha256sums rather than using copypasta on Firefox's
SHA512SUMS file.

Would it be nice to use the same checksums? Yes. Am I afraid I am
running malicious Firefox packages? No.

Open a bugreport. Or show us where you brought it to the attention of
the maintainer.

> in Gentoo they use 3 mds and in Debian they use 2 mds (for all
> packages, regardless of what upstreams do or do not do (in Debian's
> case they sign the files containing the mds)).[6][7]

And in Arch Linux, unlike Gentoo, packages are binary and securely
signed. Signing the sources yourself proves nothing, especially if you
don't even have a mark of trust like being a TU/Dev -- so that is
straight out for the AUR, which is where people other than the
maintainer would benefit from *the maintainer* signing the sources.

Debian does a lot of weird things, like hosting and patching the sources
themselves, I am not surprised they sign the sources themselves.

> there are a few package maintainers who insist on using and/or are
> still using only a part of the commit or tag hash. the whole commit
> or tag hash must be used, always.

Pointers? Bugreports?

> the refusal to future-proof.[8] i talked with the lsof upstream. he
> told me that he has retired, that he is old, and that he might stop
> maintaining it. it is unlikely that he will create a new keypair any
> time soon and he might never do that.

What? Creating a key is pretty easy.

Arch Linux doesn't even have a gnupg1 package, if you want to blame
someone for the absolute inability to validate that key on Arch Linux
(independent of makepkg) blame the GnuPG developers for dropping support
of insecure and tremendously outdated keys.

The foundational premise of GnuPG here, seems to be that such keys offer
very little security, the kind that isn't worth having.
Why doesn't the lsof developer future-proof himself, with 5 minutes of
effort? If he does so, we will be able to use the signatures!

> another bad thing that many AL team members do, is connecting to irc
> servers without using tls and certificate verification.

Assuming they care about being securely identified on IRC. Maybe they do
connect securely when they care about proving their identity for a
specific conversation where it matters.

I will grant you that for common sense alone you might as well connect
securely whenever possible as it doesn't cost anything. But equally, it
doesn't cost anything to *not* do so.

-- 
Eli Schwartz