Request: Please cryptographically sign all releases (PGP)

1

This is a ticket to request iodéOS to sign releases cryptographically. Please copy and paste this into GitLab, since it’s not possible for users to create bug reports or feature requests with the iodéOS project.

Description

Currently it is not possible to verify the authenticity or cryptographic integrity of the downloads from gitlab.iode.tech because the releases are not cryptographically signed.

This makes it hard for iodéOS customers to safely obtain the iodéOS software.

Steps to Reproduce

  1. Go to the iodéOS website iode[.]tech
  2. Click “iodéOS” in the navigation bar iode[.]tech/iodeos/
  3. Click “Install iodéOS for free” iode[.]tech/installation/
  4. Click “alternative way of installing iodéOS here” gitlab.iode[.]tech/ota/ota
  5. Click on your device (eg Pixel 8) gitlab.iode[.]tech/ota/release/-/tree/master/shiba
  6. Look for the release signature
  7. ???

Expected behavior: [What you expected to happen]

A few things are expected:

  1. I should be able to download the iodéOS 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 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.

2 Likes
2

Note: I had to break a lot of the links in the post above, because error:

new users can only put 4 links in a post

3

Note that providing a hash in-band provides no security (just integrity from corruption).

For security (to verify the authenticity of a given release), we’d need a pinned, iode-specific release-signing PGP key and cryptographic signatures of release (or signatures of the release digest file)

4

For reference, here’s how release signatures was implemented by other privacy-focused Android ROMs

  1. Graphene OS
  2. CalyxOS

If you need more historic examples where an open-source project had their publishing infrastructure breached and introduced a vector (sometimes successful) for Supply Chain Attacks against their users (which can be detected by proper release signing), see this list (specifically taking note where the Type of compromise = Publishing Infrastructure):

Worthy projects of note who were victim to this sort of attack (which could be detected by release signing):

  1. Linux Mint
  2. Monero
  3. Canonical (Ubuntu)
  4. Gentoo
  5. Handbrake
  6. etc
5

Though you could use non-standard cryptographic signatures (like OpenSSH or minisign), I would strongly encourage using gpg, as it’s the industry standard with the most adoption and mature PKI.

For best-practices, see also:

  1. Signing Releases - Apache Infrastructure Website
  2. Signing System — OpenDev System Documentation documentation
  3. Subkeys - Debian Wiki
  4. OpenPGP Best Practices - riseup.net