Triplea: Publish public key used to verify release artifact checksum signatures

[ssoloff]

This issue is a follow-up to #2463, which implemented signing of the release artifact checksum files to ensure their integrity. In order for users to verify the signatures, they need access to the public key corresponding to the private key used to create the signatures. The purpose of this issue is to discuss how we should distribute that public key.

I'll start off by proposing two possible solutions:

---

1. Publish via web page

In this solution, we would embed the public key on a web page along with its fingerprint. The web page should be served via HTTPS to ensure the public key and fingerprint can't be altered by a MITM. An example of this solution for another project can be found here.

I was going to originally suggest we use the Download page of the website, but I keep forgetting we haven't yet gotten HTTPS working for this site.

An alternative would be to place the public key and fingerprint in the wiki or README and simply place a link to the appropriate location on the Download page.

2. Publish via keyserver

In this solution, we would simply publish the public key via a GPG keyserver. An example of this solution for another project can be found here.

We would still have to provide instructions for importing the key. Again, probably via a link on the Download page to the wiki or README.

---

I'm leaning towards the following solution:

• Start by publishing the public key via (1) and eventually move to (2) simply because there are fewer moving parts.
• Add a "Verifying releases" section to the README.
  
  
  
  • Include the ASCII-armored public key.
  
  
  • Include the public key fingerprint.
  
  
  • Include instructions for importing the public key into GPG.
  
  
  • Include instructions for verifying checksum file integrity using GPG.
  
  
  • Include instructions for verifying artifact file integrity using checksums.
  
  
• Provide a link on the Download page to the "Verifying releases" section in the README (via an HTTPS URL).

Any other ideas?

[panther2]

@ssoloff

In order for users to verify the signatures, ...

Interesting read. But from (my) the user's point of view: Why do I need such a key? I usually don't need any key to verify signatures as a user:

Regarding TripleA I just open the provided txt-file with any editor, and drag and drop the downloaded exe into a simple hash tool, such as HashMyFiles. I easily see the accordance of the SHA256 (as example), then - just see the screenshot.

The task is often even easier, as many software providers publish the signatures on their download page in an instantly readable way. In this case I simply need to hash the downloaded file accordingly.

I am sure I am missing something important here... so I hope for a brief explanation.

Thanks a lot :smile:

[ssoloff]

@panther2 Good question. TL;DR: Signing the checksums basically proves that neither the binaries nor the checksums have been modified since they were published by the development team (assuming the team's private key hasn't been compromised).

Consider what could happen if someone hacked GitHub (or there was a rogue GitHub employee). They could replace one of our installers with malicious code. Since they have the ability to replace any file in a release, they could also simply regenerate the checksums and replace those files, as well. Therefore, you'd end up thinking nothing was wrong because "the checksums matched."

Granted, the GitHub scenario is unlikely to happen. And GitHub is probably the safest place to download our binaries because we publish them directly to GitHub from the Travis build via a secure connection. So as long as you are using HTTPS to download a release, it's highly unlikely you would ever receive compromised binaries.

However, we have no control over third parties distributing our binaries (e.g. see #1565). Every time the release artifacts are moved around, it may provide an attacker with the opportunity to substitute their own binaries and checksums.

This might be an extreme example, but someone could modify our installers to bundle adware or some other undesirable feature with them and distribute them on their own site. This was actually a big problem on SourceForge several years ago, in that SF themselves were injecting the adware.

If the checksums are signed, then the user can verify that they haven't been modified since they were published by whoever signed them. If the user is guaranteed that the checksums have not been modified, and the checksums match the binaries, then the user is also guaranteed that the binaries have not been modified.

Obviously, this puts some of the onus for security on the user:

• Users must somehow be educated that they need to verify signatures and checksums, and not simply download something from the Internet and "just run it."
• Users must "trust" that the entity that signed the checksums is who they really say they are. This is a huge topic. In PGP/GPG, this is addressed by building a "web of trust."

[ssoloff]

The task is often even easier, as many software providers publish the signatures on their download page in an instantly readable way. In this case I simply need to hash the downloaded file accordingly.

Good suggestion. When a user clicks an installer link on the Download page, they download the file directly without ever seeing the checksum files in the release listing. So I can see how it would be more convenient for them to never have to leave the Download page to verify the checksums.

When we update the links on the Download page for each new stable release (which currently doesn't happen very often), we could easily add the checksums to the panel that drops down when you click an installer link.

The only problem I see is that the Download page is not served over HTTPS, so the checksums are susceptible to a man-in-the-middle-attack. But since the binaries themselves are served over HTTPS directly from GitHub, the worst that can probably occur is the checksums won't match, potentially confusing the user. However, the binary would be safe. We could always provide an HTTPS link to the checksums instead, but that extra click kind of defeats the purpose of your suggestion. :smile:

[panther2]

Thank you very much, @ssoloff , it is always a great pleasure to learn from the background information that you provide in a very comprehensible way.

[RoiEXLab]

@ssoloff Regarding the website problem: What about adding the hashes to the release description?
It's currently unused and we could display it on the website.

[ssoloff]

@RoiEXLab Great idea. We might even be able to automate that as part of the Travis build.

[ssoloff]

I added a temporary wiki page that captures the information needed to resolve this issue. The content of this page is subject to change depending on how the team decides to resolve this issue (e.g. if the keyserver distribution mechanism is selected, the instructions for importing the GPG public key must be updated).

[ssoloff]

Bumping...

After writing that wiki page and seeing just how much information it contains, I'm reconsidering the idea of embedding all of that in the README. I'm thinking it might be better to just add a "Verifying Binaries" section to the README that links to the wiki.

[ssoloff]

triplea-game/triplea-game.github.io#259 adds a link to the wiki from the Downloads page. I don't think it's necessary to add anything to the README because the README already links to the Downloads page.