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

[Kieran Colford]

On Fri, Feb 24, 2017, 8:52 AM Bruno Pagani, <bruno.n.pagani at 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.

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.

-- 

Signed, Kieran Colford