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

[Bruno Pagani]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 520 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20170224/0405d81c/attachment.asc>