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#21791 -- Eli Schwartz
signature.asc
Description: OpenPGP digital signature
