Bug #15419

Detect earlier in the dev process if we're breaking automatic upgrades

Added by intrigeri 2018-03-16 16:46:37 . Updated 2018-09-05 16:23:40 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Build system
Target version:
Tails_3.9
Start date:
2018-06-28
Due date:
% Done:

100%

Feature Branch:
bugfix/15419-detect-uid-and-gid-changes
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Upgrader
Deliverable for:

Description

At least twice we had to disable automatic upgrade paths because they would create a broken Tails system:

  • upgrading to 3.0.1 (Bug #13426)
  • upgrading to 3.6

The first time this happened we added a manual test (commit:eca3d1001236570cc6a26fd2a961710a0e151ca2) to ensure we would detect that during our QA. But as 3.6 shows, this was not enough to avoid releasing something broken so let’s ensure we detect such matters as early as possible, before we’ve invested too much time into QA: this will increase the chances we have time to fix the problem and release something that can be upgraded to automatically.

My plan has three parts:

  1. Implement something that checks the UID and GID of the debian-tor user at ISO build time and aborts the build if any of them has changed. This is what this ticket is about. I’ll do the same for the Upgrader’s users as I suspect they might be affected by the same problem.
  2. Find out what’s going on with Exim: it’s been involved in this problem twice and I think we could do something cheap in order to decrease the chances such problems happen. That’s Bug #15418 and the follow-up is Bug #15690.
  3. Implement a better solution in Tails 4.0, needed, depending on the timing of Feature #8415 vs. Feature #15281. See Bug #15407 for details.

Subtasks

Related issues

Related to Tails - Bug #15407: Prevent system user uid:s and gid:s from changing between releases Resolved 2018-06-28
Related to Tails - Bug #15418: Find out what's going on with Exim in our ISO build process Resolved 2018-03-16
Related to Tails - Bug #15424: Use fixed UID and GID for debian-tor Rejected 2018-03-16
Blocks Tails - Bug #15690: Stop installing all "Priority: standard" packages only to remove some of them later Resolved 2018-06-29
Blocked by Tails - Bug #15695: Avoid breaking automatic upgrades to Tails 3.9 Resolved 2018-06-30

History

#1 Updated by intrigeri 2018-03-16 16:47:40

  • related to Bug #15407: Prevent system user uid:s and gid:s from changing between releases added

#2 Updated by intrigeri 2018-03-16 16:48:33

  • related to Bug #15418: Find out what's going on with Exim in our ISO build process added

#3 Updated by segfault 2018-03-16 20:02:16

  • related to Bug #15424: Use fixed UID and GID for debian-tor added

#4 Updated by intrigeri 2018-03-16 21:17:47

  • Target version changed from Tails_3.6.1 to Tails_3.7

#5 Updated by intrigeri 2018-04-14 08:17:34

  • Target version changed from Tails_3.7 to Tails_3.8

My initial plan probably won’t work (Bug #15424#note-12) and after almost a month I still haven’t logs for Bug #15418 => let’s discuss timing/relevance on Bug #15407.

#6 Updated by intrigeri 2018-06-19 16:28:49

  • Target version changed from Tails_3.8 to Tails_3.9

#7 Updated by intrigeri 2018-06-28 20:29:27

Regarding exim4, I’ve completed the research: Bug #15418#note-16.

#8 Updated by intrigeri 2018-06-28 20:48:15

  • Status changed from Confirmed to In Progress

> Implement something that checks the UID and GID of the debian-tor user at ISO build time and aborts the build if any of them has changed. This is what this ticket is about. I’ll do the same for the Upgrader’s users as I suspect they might be affected by the same problem.

On Bug #15424 we tried to implement something more elaborate and failed but I think we should at least implement the detection part, even if we can’t implement the more elaborate, “automatically use a fixed UID/GID” part. I’ll keep tracking this here.

> Find out what’s going on with Exim: it’s been involved in this problem twice and I think we could do something cheap in order to decrease the chances such problems happen. That’s Bug #15418.

Done. To avoid such problems, I think our best option is to stop passing --tasks standard to lb config and explicitly list the packages we want to install in config/chroot_local-packageslists/*.list. And then every time we upgrade to a new version of Debian, we create a ticket to update that list, based on the current set of Priority: standard packages in that version of Debian. Using a separate file will make this clearer and easier to maintain. I’ll create a dedicated ticket about it.

> Implement a better solution in Tails 4.0: that’s Bug #15407.

… might not be needed, depending on the timing of Feature #8415 vs. Feature #15281. See Bug #15407 for details.

#9 Updated by intrigeri 2018-06-29 12:37:17

  • related to Bug #15690: Stop installing all "Priority: standard" packages only to remove some of them later added

#10 Updated by intrigeri 2018-06-29 12:38:00

intrigeri wrote:
> Done. To avoid such problems, I think our best option is to stop passing --tasks standard to lb config and explicitly list the packages we want to install in config/chroot_local-packageslists/*.list. And then every time we upgrade to a new version of Debian, we create a ticket to update that list, based on the current set of Priority: standard packages in that version of Debian. Using a separate file will make this clearer and easier to maintain. I’ll create a dedicated ticket about it.

That’s now Bug #15690.

#11 Updated by intrigeri 2018-06-29 16:42:05

  • % Done changed from 0 to 10
  • Feature Branch set to bugfix/15690-stop-installing-all-priority-standard-packages

#12 Updated by intrigeri 2018-06-29 18:20:21

  • related to deleted (Bug #15690: Stop installing all "Priority: standard" packages only to remove some of them later)

#13 Updated by intrigeri 2018-06-29 18:20:27

  • blocks Bug #15690: Stop installing all "Priority: standard" packages only to remove some of them later added

#14 Updated by intrigeri 2018-06-29 18:20:43

  • Feature Branch changed from bugfix/15690-stop-installing-all-priority-standard-packages to bugfix/15419-detect-uid-and-gid-changes

#15 Updated by intrigeri 2018-06-30 09:32:19

Interestingly, the check I’ve added identified GID differences (monkeysphere, debian-tor) between 3.8 and current devel. The good news is that it’s a useful test. The bad news is that we need to fix that before 3.9 is released.

#16 Updated by intrigeri 2018-06-30 11:34:48

  • related to Bug #15695: Avoid breaking automatic upgrades to Tails 3.9 added

#17 Updated by intrigeri 2018-06-30 11:39:45

  • Description updated

#18 Updated by intrigeri 2018-06-30 12:51:15

  • % Done changed from 10 to 50

I’m happy with the current state of this branch but we can’t merge it until Bug #15695 is fixed, otherwise devel will FTBFS.

#19 Updated by intrigeri 2018-06-30 12:51:27

  • related to deleted (Bug #15695: Avoid breaking automatic upgrades to Tails 3.9)

#20 Updated by intrigeri 2018-06-30 12:51:35

  • blocked by Bug #15695: Avoid breaking automatic upgrades to Tails 3.9 added

#21 Updated by intrigeri 2018-08-14 14:57:59

  • Assignee changed from intrigeri to segfault
  • Estimated time set to 0 h
  • QA Check set to Ready for QA

This branch is included in the one for Bug #15695 but you might want to review it first, which could make it slightly easier to understand what Bug #15695 is about.

#22 Updated by intrigeri 2018-08-14 15:49:19

  • Assignee changed from segfault to CyrilBrulebois

#23 Updated by intrigeri 2018-08-14 16:54:30

  • Status changed from In Progress to Fix committed
  • Assignee deleted (CyrilBrulebois)
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

As per Bug #15407#note-31.

#24 Updated by intrigeri 2018-08-16 09:14:31

  • Status changed from Fix committed to In Progress

Applied in changeset commit:b19084e6ef6ed499b28f176a59ab3bdde058ef4e.

#25 Updated by intrigeri 2018-08-16 09:14:32

  • Status changed from In Progress to Fix committed

Applied in changeset commit:a158c465247a895b77e728b16692514cbd37a99a.

#26 Updated by intrigeri 2018-09-05 16:23:40

  • Status changed from Fix committed to Resolved