Sign releases on github or website

[maltfield]

Description

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

This makes it hard for your users to safely obtain the bridge software, and it introduces them (and potentially their instance's users) to numerous vulnerabilities.

Steps to Reproduce

1. Go to the docs https://docs.mau.fi/bridges/go/setup.html?bridge=whatsapp
2. Click Github releases link in the doc's Step 1: Installation section
3. Look for signature file
4. ???
5. Get confused and open ticket

Expected behavior: [What you expected to happen]

A few things are expected:

1. I should be able to download the mautrix 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 releases' digest file, such as a SHA256SUMS.asc file) along with the release itself
3. The "instalation" section of the documentation page itself should include a link to the documentation page that describes how to do the above two steps

Actual behavior: [What actually happened]

There's just literally no information on verifying downloads, and it appears that it is not possible to do so.

[maltfield]

I see that you already provide a sha256sums.txt asset for your releases.

As I'm sure you're aware, hashes do not provide security -- unless those hashes are signed. Hashes without signatures protect against download corruption; they do not provide any security.

An example attack that would be protected by signatures is a Publishing Infrastructure Compromise. Here's a great list of historically relevant cases where this happened:

• https://github.com/cncf/tag-security/tree/main/supply-chain-security/compromises

The easiest solution to this ticket (to provide a way for users to verify the authenticity of your release after download and before install) would be to sign your sha256sums.txt file, either

1. with an "iinline signature" in the same sha256sums.txt file, or
2. in a separate "detached signature" file, perhaps named sha256sums.txt.sig

[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 examples of "verifying this release" project documentation, see:

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