On 02/23/2017 10:16 PM, Mike Swanson wrote:
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.”
I encourage you to run `git archive` on your local master repo, and generate a GPG signature against that... it will be reproducible in the autogenerated version. Then upload the GPG signature as a release artifact. Because you're right, it is sheer laziness. Downloading a potentially *huge* git repo just to verify signatures, is madness. Try applying that logic to the linux kernel... *cloning* it begins to approach the length of time required to *build* it. Knowing beforehand, how many commits to specify with --depth, is not a reasonable answer. :)
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.
Fortunately, in pacman-git, makepkg now knows how to validate git signed commits/tags, same as tarballs. :) See https://lists.archlinux.org/pipermail/pacman-dev/2017-January/thread.html#21... -- Eli Schwartz