Parity-ethereum: GPG/PGP signed binaries hashes

[gavofyork]

Auto-published on parity.io.

[MicahZoltu]

Let me know if this should go in a separate issue, but it would be nice if the Releases listed in GitHub were also "Verified" (signed).

Here is how: https://help.github.com/articles/signing-commits-using-gpg/
Here is an example (1.0.4 specifically): https://github.com/zcash/zcash/releases

[5chdn]

This issue is labelled with _security_: The client fails to follow expected, security-sensitive, behaviour. However, it is inactive for several months, and neither assigned nor attached to a certain milestone.

Please assign this issue to someone at devops and add a deadline/milestone within 7 days, or close the issue if fixed otherwise.

[5chdn]

@MicahZoltu #6180

[5chdn]

From #6473

I went to download parity and noticed that the release section lists md5 sums. Why is a secure hashing algorithm not being used? Why not use signatures with a tool like https://jedisct1.github.io/minisign/?

[5chdn]

I could sign the binaries if desired, preview:

https://gist.github.com/5chdn/93da7b952f1294152b3c3e20f9953eea

[folsen]

@5chdn We now have some version of this right? If not, it should be considered as part of the release management and added as a separate issue to the devops tracker for automation.

[5chdn]

Moved https://github.com/paritytech/devops/issues/101

[lrvick]

Is there any status update on this? paritytech/devops is a private repo.

The current binary release method is subject to the following attack surface:

• Maintainer/reviewer is compromised
• Solitary system that builds release is compromised
• Github CDN/database are compromised
• Any Github production engineer is compromised

The threat profile my org works under can't tolerate the latter three points, and thus we are forced to verify tag signatures and build releases from source which creates added burdon on our infrastructure team.

If you want binary releases people can trust I suggest:

• Ensure your builds are deterministic
• Have CI systems verify git tag signatures
  
  
  
  • Verify commit signature in whitelisted keys
  
  
  • Verify tag signature by -different- key in whitelisted keys (enforce 2 people to release)
  
  
• Multiple CI systems build and publish signatures for identicial binary hash for release

The Bitcoin Core team gets this mostly right and you might want to use some of their work as a reference here:

https://github.com/bitcoin-core/gitian.sigs/
https://github.com/bitcoin-core/docs/blob/master/gitian-building.md