Le 24/02/2017 à 16:41, Kieran Colford a écrit :
On Fri, Feb 24, 2017, 8:52 AM Bruno Pagani, <bruno.n.pagani@gmail.com> wrote:
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
I agree that PGP everywhere is absolutely something to push for. On the other hand, not every developer is in the web of trust strong set and if you're downloading the package sources from Github then that's probably where you got the PGP key id from as well. An attacker who can highjack your TLS secured source download when you bump the package version could also have fed you a forged PGP key id when you first made the package. Upgrading to stronger checksums is only marginally less secure than using PGP.
That was part of my answer to NicoHood on aur-general in my TU application: PGP everywhere for sure, but not anyhow. PGP done without care is worth nothing, and same goes for the verification. Yes, this requires time. But any security system requires trust, and thus time. ;)
I think we ought to settle on what to do about these checksums. MD5 and SHA-1 are not strong enough to provide security but they're also too bloated for mere error correction. A change is definitely needed and we should decide on which direction to take.
I think that *sums should only be provided for integrity, not authenticity. I’m not an Arch Dev, nor a pacman/makepkg one though… Regards, Bruno