Project

General

Profile

Bug #16420

Update the deb.tails.boum.org archive signing key

Added by intrigeri 5 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
High
Assignee:
-
Category:
Infrastructure
Target version:
Start date:
02/05/2019
Due date:
% Done:

100%

Feature Branch:
bugfix/16420-update-tails-apt-key
Type of work:
Sysadmin
Blueprint:
Starter:
Affected tool:

Description

It expires on 2019-05-01 (spotted by our test suite).

High prio as this makes the output of our CI less useful.


Related issues

Blocks Tails - Feature #13242: Core work: Sysadmin (Maintain our already existing services) Confirmed 06/29/2017

Associated revisions

Revision 5a7a43c2 (diff)
Added by bertagaz 4 months ago

Update tails' apt GnuPG key expiration.

Refs: #16420

Revision 05c7bc93
Added by intrigeri 4 months ago

Merge remote-tracking branch 'origin/bugfix/16420-update-tails-apt-key' into stable (Fix-committed: #16420)

History

#1 Updated by intrigeri 5 months ago

  • Blocks Feature #13242: Core work: Sysadmin (Maintain our already existing services) added

#2 Updated by intrigeri 5 months ago

(Assigning to bertagaz as the problem started during his shift; nobody filed a ticket about it back then but we got plenty of notifications on the -rm@ list, to which bertagaz is subscribed.)

#3 Updated by intrigeri 4 months ago

@bertagaz, what's your plan on this front? Do you need help?

#4 Updated by bertagaz 4 months ago

intrigeri wrote:

@bertagaz, what's your plan on this front? Do you need help?

Nop, I'll tackle that today or tomorrow.

#5 Updated by intrigeri 4 months ago

Nop, I'll tackle that today or tomorrow.

Great! :)

#6 Updated by bertagaz 4 months ago

  • Status changed from Confirmed to In Progress

#7 Updated by bertagaz 4 months ago

  • Assignee changed from bertagaz to intrigeri
  • QA Check set to Ready for QA
  • Feature Branch set to bugfix/16420-update-tails-apt-key

intrigeri wrote:

Nop, I'll tackle that today or tomorrow.

Great! :)

Took a bit more time, but is now ready to be merged in the Tails main repo. Branch is based on stable and should be merged into stable and devel.

I've already updated it in our puppet manifests (in the tails and tails_secrets_apt modules) and deployed it on apt.lizard. Please have a look there also to see if I did not forget about something.

#8 Updated by intrigeri 4 months ago

  • Status changed from In Progress to Fix committed
  • % Done changed from 0 to 100

#9 Updated by intrigeri 4 months ago

Took a bit more time, but is now ready to be merged in the Tails main repo. Branch is based on stable and should be merged into stable and devel.

Thanks, merged. We'll see how it goes on Jenkins once it's back on track (see groente's email on -sysadmins@).

I've already updated it in our puppet manifests (in the tails and tails_secrets_apt modules) and deployed it on apt.lizard. Please have a look there also to see if I did not forget about something.

bertagaz, @reprepro-tagged-snapshots@apt hasn't the updated key. IIRC, just like reprepro, Puppet will initialize it correctly when setting up a new system but the pieces to update the key are missing. I guess that fetching from the keyservers should fix it. Maybe we should run parcimonie for this user too. But reprepro-time-based-snapshots@apt has the updated key, not sure why.

#10 Updated by intrigeri 4 months ago

@bertagaz, see previous comment.

#11 Updated by intrigeri 4 months ago

  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

#12 Updated by bertagaz 4 months ago

  • Status changed from Fix committed to In Progress
  • Assignee set to intrigeri
  • QA Check changed from Pass to Info Needed

intrigeri wrote:

bertagaz, @reprepro-tagged-snapshots@apt hasn't the updated key. IIRC, just like reprepro, Puppet will initialize it correctly when setting up a new system but the pieces to update the key are missing. But reprepro-time-based-snapshots@apt has the updated key, not sure why.

Indeed, I did not catch that only the reprepro-time-based-snapshots keyring was updated. I guess this one did because of the tails::reprepro::snapshots::time_based::import_upstream_keys resource. I've wrongly assumed other reprepros had that kind of mechanism.

I guess that fetching from the keyservers should fix it. Maybe we should run parcimonie for this user too.

Or maybe factorizing tails::reprepro::snapshots::time_based::import_upstream_keys so that it can be used by other reprepros could be simpler? This sounds like a left over from the reprepro work. Shall I open a ticket and assign it to you?

#13 Updated by intrigeri 4 months ago

I guess that fetching from the keyservers should fix it. Maybe we should run parcimonie for this user too.

Or maybe factorizing tails::reprepro::snapshots::time_based::import_upstream_keys so that it can be used by other reprepros could be simpler? This sounds like a left over from the reprepro work. Shall I open a ticket and assign it to you?

@bertagaz, thanks for looking into it. Yes, please file a ticket about this bug and tentatively assign it to me. I've not looked at the code yet so I don't know which solution I prefer at the moment. I'm interested in fixing it for personal reasons, but FTR: we have no policy nor established practice that a bug reported 3 years after delivery counts as a leftover; at that point, the responsibility of maintenance and bugfixing has long been transferred to core work.

In any case, don't wait for me to implement the long-term fix before you mitigate this problem.

#14 Updated by intrigeri 4 months ago

  • Assignee changed from intrigeri to bertagaz
  • QA Check changed from Info Needed to Dev Needed

#15 Updated by intrigeri 4 months ago

  • Status changed from In Progress to Fix committed
  • Assignee deleted (bertagaz)
  • QA Check changed from Dev Needed to Pass

Actually, the reprepro-tagged-snapshots user does not need that key: it does not run reprepro itself and does not sign anything (tagged snapshots are prepared by bin/tag-apt-snapshots as the reprepro-time-based-snapshots user, then moved into place). I'm actually pretty sure it does not even need the public key. So your job is done here and there's no ticket to create for me :)

#16 Updated by CyrilBrulebois 3 months ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF