Bug #16420
Update the deb.tails.boum.org archive signing key
100%
Description
It expires on 2019-05-01 (spotted by our test suite).
High prio as this makes the output of our CI less useful.
Subtasks
Related issues
| Blocks Tails - Feature #13242: Core work: Sysadmin (Maintain our already existing services) | Confirmed | 2017-06-29 |
History
#1 Updated by intrigeri 2019-02-05 12:24:50
- blocks Feature #13242: Core work: Sysadmin (Maintain our already existing services) added
#2 Updated by intrigeri 2019-02-05 12:25:40
(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 2019-02-14 09:47:05
@bertagaz, what’s your plan on this front? Do you need help?
#4 Updated by bertagaz 2019-02-14 11:21:34
intrigeri wrote:
> @bertagaz, what’s your plan on this front? Do you need help?
Nop, I’ll tackle that today or tomorrow.
#6 Updated by bertagaz 2019-02-19 15:30:14
- Status changed from Confirmed to In Progress
Applied in changeset commit:tails|5a7a43c2bd49d4573aef2b47357fa6a162b82906.
#7 Updated by bertagaz 2019-02-19 15:33:59
- 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 2019-02-19 17:46:18
- Status changed from In Progress to Fix committed
- % Done changed from 0 to 100
Applied in changeset commit:tails|05c7bc931ee2b7e6347e54b14e3e9bb05601fc36.
#9 Updated by intrigeri 2019-02-19 17:49:46
> 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-snapshotsapt@ has the updated key, not sure why.
#10 Updated by intrigeri 2019-02-19 17:50:17
@bertagaz, see previous comment.
#11 Updated by intrigeri 2019-02-19 17:50:32
- Assignee deleted (
intrigeri) - QA Check changed from Ready for QA to Pass
#12 Updated by bertagaz 2019-02-25 12:30:21
- 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-snapshotsapt@ 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 2019-02-25 15:03:01
>> 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 2019-02-25 15:08:13
- Assignee changed from intrigeri to bertagaz
- QA Check changed from Info Needed to Dev Needed
#15 Updated by intrigeri 2019-03-06 08:38:58
- 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 2019-03-20 14:26:43
- Status changed from Fix committed to Resolved