I also recommend adding a KEYS file to the root of your repo (located along-side files like README.md and LICENSE.md), 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

Hi, they are cryptographically signed, here's a support entry about it:
https://tuta.com/support#verify-desktop

Is this what you meant?

Sorry, no, I don't think this addresses the issue at all:

A few things are expected:

1. I should be able to download the tuta release-signing PGP key out-of-band from popular third-party keyservers (eg https://keys.openpgp.org/)
2. 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

1. I can't find where to download the tuta release signing key out-of-band (from several distinct third-party servers)
2. I can't find any documentation that shows which commands to run to verify a given release
3. The downloads page doesn't link to the documentation describing how to do [1] and [2]
4. Obviously any solution to verify tuta releases shouldn't require users to download a tool that can't itself be verified. Or whoose signature would require the tool to verify itself.

I recommend PGP because gpg can be safely installed, and there's already infrastructure and standards in-place for this.

There's acceptable alternatives to PGP, but the tools used to verify the signature must be available in major OS repos, so that the prerequisites needed to verify the tuta release can themselves be downloaded in a way that cryptographically verifies their integrity.

The support entry I linked above references this file for instructions:
https://github.com/tutao/tutanota/blob/master/buildSrc/installerSigner.js

Which explains how to download the key from Github and run the verification command:

I think you will agree that openssl is a widespread enough tool that can be trusted.

I would agree that the instructions should be more clear (it should be possible to copy and paste the command) and should be more accessible but I would argue that the process itself is fine.

I think you will agree that openssl is a widespread enough tool that can be trusted.

Yes. While I don't recommend openssl for this purpose (it's not the industry standard for release signing, and I don't think it has infrastructure in-place for keyservers and cross-signing like we have with PGP), it does solve #4 above.

We still need to address 1-3 before this ticket can be resolved

1. I can't find where to download the tuta release signing key out-of-band (from several distinct third-party servers)
2. I can't find any documentation that shows which commands to run to verify a given release
3. The downloads page doesn't link to the documentation describing how to do [1] and [2]

1. The tuta release signing key needs to be uploaded to multiple distinct domains (eg github.com, tuta.com, reddit, lemmy, bluesky, mastodon, etc).
2. The tuta documentation (on the tuta website, not buried in some script's comments) needs to be updated describing how to download the release signing key from multiple distinct domains and the commands to execute to verify releases
3. The download page itself (immediately next to where the use downloads the release payload) needs to link to the documentation above for verifying the authenticity of the release payload

Please let me know if you'd like examples for how other organizations and open-source projects do this, and I can link to some here (so you can use them as a template).