Sign Releases (PGP, GPG)

[maltfield]

Is your feature request related to a problem?

Currently it is not possible to verify the authenticity or cryptographic integrity of the notation releases from github.com because the releases are not cryptographically signed.

This makes it hard for notation users to safely obtain the notation software, and it introduces them (and potentially future things they try to verify with notation's cli tools) to watering hole attacks.

What solution do you propose?

A few things are expected:

1. I should be able to download the notation release-signing PGP key out-of-band from popular third-party keyservers (eg https://keys.openpgp.org/)
2. I should be able to download a cryptographic signature of the release (or, better, the signature of the releases' checksum file, such as a _checksums.txt.asc file) along with the release itself
3. The downloads page itself should include a link to the documentation page that describes how to do the above two steps

What alternatives have you considered?

Signing your releases with minisign would be ok, but I think it's best to stick to tried-and-true best-practices with gpg.

You could also release the software on repos like apt that have digests that are signed, but the debian maintainer is going to prefer you to sign your releases with your own PGP key for them to securely obtain it from you, anyway.

In any case, you need to sign your own releases.

Any additional context?

Steps to Reproduce

1. Go to the releases page https://github.com/notaryproject/specifications/releases/tag/v1.1.0
2. Look for signature file
3. ???
4. Go to the install docs page https://notaryproject.dev/docs/user-guides/installation/cli/
5. Look for instructions how how to verify the release with a cryptographic signature
6. ???
7. Get confused and open ticket

[maltfield]

A note on why checksums alone do not fix this problem:

It's possible for a very powerful adversary to compromise your release infrastructure (or the infrastructure between the server and the client) and get new users to download a malicious version of the release and checksums.

Remember: monero's release infrastructure has already been comprimised once. And here's a great list of historically relevant cases where this happened:

• https://github.com/cncf/tag-security/tree/main/community/catalog/compromises

Besides release signing helping to protect against release infrastructure comprise, https is vulnerable to MITM attacks when downloading the checksum file. This is not an issue with TLS inherently (it would be fine if a user used a pinned certifiate), but it's an issue with X.509. Here's some historically relevant cases where this was an issue:

• https://security.stackexchange.com/questions/234052/where-can-i-find-a-list-of-all-government-agencies-with-cas-in-pki-root-stores

These issues are fixed by signing your releases with a PGP key that's well-integrated in the WOT and uploaded to several distinct domains.

[maltfield]

For best-practices, see also:

1. https://infra.apache.org/release-signing
2. https://docs.opendev.org/opendev/system-config/latest/signing.html
3. https://wiki.debian.org/Subkeys
4. https://riseup.net/en/security/message-security/openpgp/best-practices

[maltfield]

For the documentation required to fix this issue, please see the following "verifying this release" documentation from other open-source projects as a template

1. https://www.apache.org/info/verification.html#CheckingSignatures
2. https://docs.featherwallet.org/guides/linux#verifying-the-download-optional
3. https://support.torproject.org/tbb/how-to-verify-signature/
4. https://ubuntu.com/tutorials/how-to-verify-ubuntu
5. https://tails.net/install/expert/index.en.html#verify-key
6. https://calyxos.org/install/verify/#additional-verification