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.