Tails

#2 Updated by sajolida 2013-09-29 01:16:30

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 2014-03-29 11:35:12

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 2015-01-03 01:41:54

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.

#5 Updated by sajolida 2015-01-03 18:29:07

Indeed. Irregulator: do you feel like working on a patch?

#6 Updated by irregulator 2015-01-04 00:42:03

sure, I’ll return with an attached one.

#11 Updated by sajolida 2015-01-08 19:27:53

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?