[FR] Add Cryptographic Signatures for all releases

[maltfield]

Describe the feature

Description

Currently it is not possible to verify the authenticity or cryptographic integrity of the downloads from sourceforge.net (or seemingly any other domain) because the releases are not cryptographically signed.

This makes it hard for BlissOS users to safely obtain BlissOS, and it introduces them to watering hole attacks.

Steps to Reproduce

1. Go to the https://blissos.org
2. Click the big blue Download button in the top-right of the header
3. Search the page for "verify" or "signature" or "gpg" or "pgp"
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 BlissOS 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 downloads 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.

Links to commits (if applicable)

No response

Additional information or screenshots

No response

[electrikjesus]

We provide sha256 sum files:

And Sourceforge provides these hashes as well:

[maltfield]

I see that some BlissOS releases have a cooresponding .sha file.

That file is empty but, regardless, hashes do not provide security, unless those hashes are cryptographic hash functions (eg not sha1) and those 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. 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/supply-chain-security/compromises

[maltfield]

@electrikjesus this ticket is to address security (authenticity), not corruption (integrity).

[maltfield]

I also recommend adding a KEYS file to the root of your repo (located along-side files like COPYING and AUTHORS), per the KEYS standard established by Apache

• https://infra.apache.org/release-signing#keys-policy

For more 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