Fix key trusting instructions to work when we update our signing key
The simple version of the instructions that we give for people to increase their trust in our signing key rely on the sha256sum of the key file itself:
When we update our signing key file with new signatures, the hash of that file changes. This might lead users to think that they downloaded a wrong signing key file.
#2 Updated by sajolida over 6 years ago
This task requires thinking about other ways of comparing several downloads of the signing key file and propose a way of comparing them that is not broken when we update the signing key file with new signatures.
Ideas to explore:
- Is it possible to compare the fingerprints of those downloads without importing them to the user keyring?
- Shall we suggest to import the keys, and, is it easy to explain how to interpret the gpg output when importing?
- Is it easier to explain instead that this technique doesn't work if we update the signing key file?
- If none of this works, shall we decide to never update the signing key file?
#3 Updated by intrigeri almost 6 years ago
Alternatively, we could update the release process doc to always update the signing key and the corresponding hash in the key trusting doc. This way, worst case the hash is wrong for less than 6 weeks (if someone updates the signing key independently, and forgets to update the hash).
Also, the cmp command allows to compare two files byte by byte, which could allow us to simply drop the hash.
#4 Updated by irregulator about 5 years ago
Since the signing key is served in ASCII-armored format, we can use diff as well, i.e. comparing files line by line. We can instruct users to
diff -q --from-file tails-signing*.key
If all files are identical the command will produce no output; user may trust the key file. If a file differs, the output will be something like:
Files tails-signing-desktop.key and tails-signing-laptop.key differ
then something's wrong.
#11 Updated by sajolida about 5 years ago
I like this technique! Thanks for proposing it.
What about adding the '-s' option as well? Then there would always be an output, even if all keys are identical. For example:
amnesia@amnesia:~/keys$ diff -qs --from-file tails-signing*.key Files tails-signing-1.key and tails-signing-2.key are identical Files tails-signing-1.key and tails-signing-3.key are identical Files tails-signing-1.key and tails-signing-4.key are identical Files tails-signing-1.key and tails-signing-5.key are identical Files tails-signing-1.key and tails-signing.key differ
I think that visual feedback is important in security processes, probably even more than in other areas. And the fact that a successful command means no output would make me dubtious about whether the command did its job.
On top of that, if you agree with this change, then it would further simplify the rest of the instructions as the output makes it directly explicit which keys are identical. Maybe we can skip giving additional indications on how to interpret the output.
Still, it could be nice to leave an example with some identicals and differing keys. So people know what to expect and can detect possible bugs. Examples are always good. See principle 8 from http://idratherbewriting.com/2014/06/20/10-technical-writing-principles-to-live-by :)
What do you think?
#13 Updated by irregulator about 5 years ago
I agree with both '-s' and visual examples. So here's the new patch.