[pacman-dev] [PATCH 0/2] Deprecate md5sums, show sha256sums as an example-by-default.

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20170223/70eace2d/attachment-0001.asc>