Project

General

Profile

Feature #8769

Feature #8222: Transition to a new signing key

Feature #8740: Transition to a new signing key, phase 2

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

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

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

100%

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

Associated revisions

Revision 0996c3e5
Added by intrigeri about 5 years ago

Merge branch 'stable' into feature/8740-new-signing-key-phase-2 (Closes: #8769)

Conflicts:
features/step_definitions/checks.rb

History

#1 Updated by intrigeri about 5 years ago

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

#2 Updated by intrigeri about 5 years ago

  • Assignee set to sajolida

#3 Updated by intrigeri about 5 years ago

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

#4 Updated by sajolida about 5 years ago

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 about 5 years ago

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

#6 Updated by intrigeri about 5 years ago

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 #8730 :)

#7 Updated by sajolida about 5 years ago

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 about 5 years ago

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

#9 Updated by sajolida about 5 years ago

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

#10 Updated by sajolida about 5 years ago

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

#11 Updated by BitingBird about 5 years ago

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

#12 Updated by sajolida about 5 years ago

  • Status changed from Confirmed to Resolved

#13 Updated by sajolida about 5 years ago

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

#14 Updated by sajolida about 5 years ago

  • 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 about 5 years ago

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

#16 Updated by sajolida about 5 years ago

  • 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 about 5 years ago

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 about 5 years ago

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

#19 Updated by intrigeri about 5 years ago

  • Assignee set to intrigeri

#20 Updated by intrigeri about 5 years ago

  • 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 about 5 years ago

  • 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 about 5 years ago

  • Assignee changed from intrigeri to sajolida

#23 Updated by intrigeri about 5 years ago

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 about 5 years ago

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

#25 Updated by intrigeri about 5 years ago

  • Status changed from 11 to Resolved
  • % Done changed from 60 to 100

#26 Updated by BitingBird about 5 years ago

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

Also available in: Atom PDF