[pacman-dev] [PATCH 0/2] Deprecate md5sums, show sha256sums as an example-by-default.

Mike Swanson mikeonthecomputer at gmail.com
Fri Feb 24 03:16:19 UTC 2017


This is an interesting discussion, I don't exactly mind the points for
remaining with md5sums as the example, but I do have some issue with it:

I believe the documentation and sample PKGBUILDs should show best
practices, rather than purposely use a poor practice with the hope that
a PKGBUILD author fixes it themself.  _I_ know to replace the checksum
function with something better, to use GPG keys where possible, but a
brand new author would not, and a long-time author may not even realize
the best practices do not match what they are used to: the example
PKGBUILDs aren't being changed to show the contrary.

On false senses of security: Yes, there is some blind faith that an AUR
maintainer just so happened to provide the correct checksums, but
there's even a faith that the correct GPG keys are used and correct
source host.  Thankfully, it is usually plainly obvious if the latter is
the case. :-)

On upstream always providing GPG signature files against tarballs:
Beyond the fact that not all upstreams even do this (and you can make a
fair argument that the AUR maintainer has no firm reason to believe
_their_ download was the correct one), I'm not actually entirely
convinced that they should always be expected to do as such.

This is a difficult position to defend, and it may come down to
laziness, but hosting sites such as GitHub and GitLab provide automated
tarball generation (by just using `git archive` on the backend -- it's
easy to independently verify the archives).  Speaking from my
experience, it has become natural for me to stick with GPG-signing the
tag in Git itself and ignoring output files such as these.  It largely
comes to “If you need to verify the integrity of the source code, I
expect you to clone the repository and check that tag, and use `git
archive | $HASH` to verify the archive GitHub/GitLab provide.”

In this case, the GPG signature exists, but not in any sort of form
makepkg is expecting nor can verify.  Given that AUR PKGBUILDs can be
retrieved over https or ssh, and likewish GitHub and GitLab repositories
and files can be retrieved over https or ssh, there is already a high
confidence that a malicious actor in the middle is not tampering with
any of the sources.  If somebody _really_ wants to verify that the
PKGBUILD is using the unaltered source, no trickery, there is no way
around examining it themself, making sure the correct checksums or GPG
keys are being used, making sure no patches are changing the source
maliciously (either as files or part of the prepare/build functions),
and frankly, using the upstream project's VCS to verify tags and
generated archives.

tl;dr: I don't think PKGBUILDs can ever be automatically trusted, not
even if they use GPG signature checking.  Nor do I think they should
ever be fully distrusted if they do not.


More information about the pacman-dev mailing list