Le 24/02/2017 à 04:37, Eli Schwartz a écrit :
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. :)
Debian wrote a nice page about this: https://wiki.debian.org/Creating%20signed%20GitHub%20releases Especially the alternative local workflow at the end, that is mostly what Eli proposes above. ;) One example of package doing this is https://github.com/vector-im/riot-web, they included this easily in their release process at https://github.com/matrix-org/matrix-js-sdk/pull/351. If you’re already signing tags used for releases, signing the tarball should really be easy and as underlined by Eli, quite a good idea. So, yes, PGP everywhere please. Cheers, Bruno