Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • T tails
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 928
    • Issues 928
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 18
    • Merge requests 18
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • tails
  • tails
  • Issues
  • #15419

Closed
Open
Created Mar 16, 2018 by intrigeri@intrigeriMaintainer1 of 1 task completed1/1 task

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

Originally created by @intrigeri on #15419 (Redmine)

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

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

The first time this happened we added a manual test (eca3d100) 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 #15418 (closed) and the follow-up is #15690 (closed).
  3. Implement a better solution in Tails 4.0, needed, depending on the timing of #8415 (closed) vs. #15281 (closed). See #15407 (closed) for details.

Feature Branch: bugfix/15419-detect-uid-and-gid-changes

Related issues

  • Related to #15407 (closed)
  • Related to #15418 (closed)
  • Related to #15424 (closed)
  • Blocks #15690 (closed)
  • Blocked by #15695 (closed)
Edited May 15, 2020 by intrigeri
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking