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
signature.asc
Description: OpenPGP digital signature