Replies: 5 comments
-
I also recommend adding a For more best-practices, see also: |
Beta Was this translation helpful? Give feedback.
-
Hi, they are cryptographically signed, here's a support entry about it: Is this what you meant? |
Beta Was this translation helpful? Give feedback.
-
Sorry, no, I don't think this addresses the issue at all:
I recommend PGP because 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. |
Beta Was this translation helpful? Give feedback.
-
The support entry I linked above references this file for instructions: Which explains how to download the key from Github and run the verification command: tutanota/buildSrc/installerSigner.js Lines 21 to 24 in d511f03 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. |
Beta Was this translation helpful? Give feedback.
-
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
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). |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Description
Currently it is not possible to verify the authenticity or cryptographic integrity of the downloads from tuta.com because the releases are, apparently, not cryptographically signed.
This makes it hard for tuta customers to safely obtain the tuta software, and it introduces them (and potentially their contacts) to watering hole attacks.
Steps to Reproduce
Expected behavior: [What you expected to happen]
A few things are expected:
SHA256SUMS.asc
file) along with the release itselfActual behavior: [What actually happened]
There's just literally no information on verifying downloads, and it appears that it is not possible to do so.
Beta Was this translation helpful? Give feedback.
All reactions