Feature #8769

Document how to migrate from trusting the old key to trusting the new key

Added by sajolida 2015-01-21 18:06:15 . Updated 2015-03-22 12:07:47 .

Status:
Resolved
Priority:
Elevated
Assignee:
Category:
Target version:
Tails_1.3.1
Start date:
2015-01-21
Due date:
% Done:

100%

Feature Branch:
feature/8740-new-signing-key-phase-2
Type of work:
End-user documentation
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Subtasks

History

#1 Updated by intrigeri 2015-01-22 11:19:11

  • Priority changed from Normal to Elevated
  • Target version set to Tails_1.3.2

#2 Updated by intrigeri 2015-02-08 20:04:43

  • Assignee set to sajolida

#3 Updated by intrigeri 2015-02-08 20:04:59

  • blocked by Feature #8734: Update all documentation to trust our new signing key added

#4 Updated by sajolida 2015-03-02 17:38:19

What about doing a short blog post about that some weeks before the release?

That could serve as a transition statment and give different tips to trust the new one:

  • Check it with the old one.
  • Check it again Debian WoT.

#5 Updated by intrigeri 2015-03-03 14:07:59

  • related to Feature #8730: Publish a transition statement for our signing key added

#6 Updated by intrigeri 2015-03-03 14:15:35

> What about doing a short blog post about that some weeks before the release?

I think a blog post is a great idea. I’m not sure it’ll be short, but well :)

It doesn’t entirely address very well one use case I’m concerned about, that is: N months ago I carefully verified the Tails signing key, and now I’m downloading Tails again, and I want to verify it. If I were that person, then I’d love to see a note in the verification instructions about how to handle the key transition. Perhaps it could simply be a single sentence that points to the blog post, and could be removed, say, 3 months later.

> That could serve as a transition statment

Right. This statement will then have to make it clear exactly when we’re doing the transition (that is, at 1.3.1 release time), otherwise our old key will be invalidated too early.

If we agree on all that, then I’ll merge this ticket with Feature #8730 :)

#7 Updated by sajolida 2015-03-05 14:56:47

> Perhaps it could simply be a single sentence that points to the blog post, and could
> be removed, say, 3 months later.

Let’s do that.

> Right. This statement will then have to make it clear exactly when
> we’re doing the transition (that is, at 1.3.1 release time),
> otherwise our old key will be invalidated too early.

Sure. I’ll work on a draft this week.

#8 Updated by sajolida 2015-03-12 12:04:00

  • related to deleted (Feature #8730: Publish a transition statement for our signing key)

#9 Updated by sajolida 2015-03-12 12:04:03

  • is duplicate of Feature #8730: Publish a transition statement for our signing key added

#10 Updated by sajolida 2015-03-12 12:04:26

So I’m marking this one as a duplicate from Feature #8730. Moving the discussion there.

#11 Updated by BitingBird 2015-03-15 13:43:54

  • blocks deleted (Feature #8734: Update all documentation to trust our new signing key)

#12 Updated by sajolida 2015-03-16 14:52:45

  • Status changed from Confirmed to Resolved

Applied in changeset commit:094a53b74004d3448d7bc3a8e96fab7d602895bd.

#13 Updated by sajolida 2015-03-16 14:56:17

  • has duplicate deleted (Feature #8730: Publish a transition statement for our signing key)

#14 Updated by sajolida 2015-03-16 15:08:22

  • Status changed from Resolved to Confirmed

Still need to explain in the doc how to migrate from the old key to the new key.

#15 Updated by intrigeri 2015-03-16 16:01:37

  • Feature Branch set to feature/8740-new-signing-key-phase-2

#16 Updated by sajolida 2015-03-16 16:56:29

  • Assignee deleted (sajolida)
  • QA Check set to Ready for QA

I added notes about that:

  • Right below the download of the signature file. I believe that’s where more people would spot it.
  • At the top of each verification instructions.

#17 Updated by sajolida 2015-03-16 16:57:33

Ah, and I did some ugly inline CSS stuff because we’ll remove this after some time. So it’ll be easy to remove from there.

#18 Updated by sajolida 2015-03-16 16:59:31

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 30

#19 Updated by intrigeri 2015-03-16 17:04:51

  • Assignee set to intrigeri

#20 Updated by intrigeri 2015-03-16 18:35:14

  • Assignee changed from intrigeri to sajolida
  • % Done changed from 30 to 60

I added a few fixes on top, please review and then feel free to merge into the stable branch.

#21 Updated by sajolida 2015-03-17 13:09:04

  • Assignee changed from sajolida to intrigeri

I’m fine with your changes but when I tried to merge it into stable I got a conflict in the test suite. See:

<<<<<<< HEAD
  case key_type
  when 'signing'
    sig_key_fingerprint = TAILS_SIGNING_KEY
=======
  if key_type == 'signing'
    sig_key_fingerprint = "A490D0F4D311A4153E2BB7CADBB802B258ACD84F"
>>>>>>> origin/feature/8740-new-signing-key-phase-2

Can you take care of this as I don’t want to mess with that kind of stuff!

#22 Updated by intrigeri 2015-03-18 08:44:20

  • Assignee changed from intrigeri to sajolida

#23 Updated by intrigeri 2015-03-18 08:44:33

> Can you take care of this as I don’t want to mess with that kind of stuff!

Done in the topic branch.

#24 Updated by sajolida 2015-03-18 11:24:04

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

#25 Updated by intrigeri 2015-03-18 11:25:18

  • Status changed from Fix committed to Resolved
  • % Done changed from 60 to 100

Applied in changeset commit:0996c3e5ed84f1f9300de360f740f273cc312e5a.

#26 Updated by BitingBird 2015-03-22 12:07:48

  • Target version changed from Tails_1.3.2 to Tails_1.3.1