Project

General

Profile

Bug #6318

Fix key trusting instructions to work when we update our signing key

Added by sajolida over 6 years ago. Updated about 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Installation
Target version:
Start date:
09/28/2013
Due date:
% Done:

30%

Feature Branch:
Type of work:
End-user documentation
Blueprint:
Starter:
Yes
Affected tool:

Description

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:

https://tails.boum.org/doc/get/trusting_tails_signing_key/

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.

0001-Compare-keys-with-diff-instead-of-sha256sum.patch View (2.13 KB) irregulator, 01/08/2015 11:41 PM

History

#1 Updated by sajolida over 6 years ago

  • Starter changed from No to Yes

#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.

#5 Updated by sajolida about 5 years ago

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

#6 Updated by irregulator about 5 years ago

sure, I'll return with an attached one.

#7 Updated by irregulator about 5 years ago

  • File 0001-Compare-keys-with-diff-instead-of-sha256sum.patch added

Here's my suggestion as patch

#8 Updated by sajolida about 5 years ago

  • Assignee set to sajolida
  • Target version set to Tails_1.2.3

I'll have a look in time for 1.2.3.

#9 Updated by intrigeri about 5 years ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 30
  • QA Check set to Ready for QA

#10 Updated by BitingBird about 5 years ago

  • Category set to Installation

#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?

#12 Updated by sajolida about 5 years ago

  • Assignee changed from sajolida to irregulator
  • QA Check changed from Ready for QA to Dev Needed

#13 Updated by irregulator about 5 years ago

I agree with both '-s' and visual examples. So here's the new patch.

#14 Updated by irregulator about 5 years ago

  • File deleted (0001-Compare-keys-with-diff-instead-of-sha256sum.patch)

#15 Updated by intrigeri about 5 years ago

  • Target version changed from Tails_1.2.3 to Tails_1.3

#16 Updated by sajolida about 5 years ago

  • Assignee changed from irregulator to sajolida
  • QA Check changed from Dev Needed to Ready for QA

#17 Updated by sajolida about 5 years ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (sajolida)
  • QA Check deleted (Ready for QA)

Amazing, merged!

Also available in: Atom PDF