Feature #14823

Simulate tracking of security updates on a branch based on snapshots of Debian testing

Added by intrigeri 2017-10-10 05:14:04 . Updated 2019-08-30 20:17:44 .

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2017-10-10
Due date:
% Done:

20%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Files

security-tracker-overlay.diff (4608 B) intrigeri, 2018-02-27 11:37:41

Subtasks

History

#1 Updated by intrigeri 2017-10-10 05:14:20

#2 Updated by intrigeri 2017-10-21 17:17:50

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

I’ve pushed to a Git repo my git-svn import from Debian’s secure-testing SVN repo and the code changes that start adapting it for Tails. I don’t plan to do more work on the code until we make a decision wrt. basing Tails on Debian testing. I think I’ve reached the point where it works well enough to do what this ticket is about: only issues in packages listed in our build manifest are listed, and we can flag specific issues as ignored/postponed. I’ll do a first triaging of the open issues, pretending that Tails 3.2 was based on Buster and 3.3 (also based on Buster) will use the same set of frozen APT snapshots.

Wrt. updating this repo with git-svn: apparently it’s a total PITA to have more than 1 person doing this. For now, I’ll do it myself as part of this ticket. And of course, if we ever want to use this system in production, we’ll need to teach a robot to do the git svn fetch && git merge .. && git push .. dance a few times a day. I expect there will be merge conflicts due to our edits in data/CVE/list but we’ll see.

I pushed there:

git clone tails@git.tails.boum.org:secure-testing

IMO it’s too early for a 2nd person to invest time learning how to use the thing.

#3 Updated by intrigeri 2017-10-21 18:24:33

We didn’t freeze the APT snapshots on feature/buster so I can’t easily evaluate the “backport security fixes via uploads to an overlay APT repo” option. What I can do is one of:

  • freeze these APT snapshots to the ones used in Tails 3.2, i.e. rollback feature/buster to an older version of Debian than the one we used during our first sprint: this risks breaking stuff, doesn’t seem worth it
  • freeze these APT snapshots to something as close as possible to what we were using during the sprint: this would be ideal… except we haven’t designed the APT overlay for security uploads yet, so that’s actually more work than what I committed to do
  • forget for now about freezing APT snapshots & uploading fixes, focus on triaging issues in our security tracker for now, takes notes of the packages we should have upgraded, but freeze snapshots during next sprint and then use the (end of 2nd sprint → end of November) period to test how uploading fixes would fare

I’ll go for the third option unless someone (likely that would be anonym) else takes the lead wrt. designing & setting up that security overlay APT suite, and does it without needing much help from me; if this happens, then I’m happy to do go with the 2nd option.

#4 Updated by intrigeri 2017-10-21 18:40:26

  • % Done changed from 10 to 20

If we were going to release something based on Debian testing with APT snapshot frozen like the 3.2 ones, today I would want to:

  • upload gdk-pixbuf, git, icu, libidn2-0, nss, openjpeg2, wpa
  • look more closely at the linux and xorg-server issues

I’ll do the same analysis again in ~7 days.

#5 Updated by intrigeri 2017-10-29 17:26:11

Today I would want to:

I’ll do this again in ~1 week.

FTR this took me 30 minutes, most of it waiting for git-svn to fetch SVN changesets. My initial merge worked fine without conflicts. After my triaging I merged again and there was one — trivially resolved — conflict (I had flagged a CVE that a security team member was triaging at the same time).

#6 Updated by intrigeri 2017-11-07 18:33:24

  • Target version changed from Tails_3.3 to Tails_3.5

We need to adjust our plans on this project, requested input from tails-dev@.

#7 Updated by intrigeri 2017-11-25 15:25:14

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

#8 Updated by intrigeri 2017-12-31 14:08:55

Debian’s security tracker repo was moved to Git :) I’ll rebase our changes on top of that Git tree next time I work on this topic.

#9 Updated by intrigeri 2018-01-01 16:39:17

  • blocked by deleted (Feature #13244: Core work 2017Q4: Foundations Team)

#10 Updated by intrigeri 2018-01-01 17:17:12

intrigeri wrote:
> Debian’s security tracker repo was moved to Git :) I’ll rebase our changes on top of that Git tree next time I work on this topic.

Well, I could not wait: https://git-tails.immerda.ch/security-tracker/ :)

#11 Updated by intrigeri 2018-02-27 11:39:40

The attached patch (from Bastian Blank <waldi@debian.org>) might allow us to maintain our own “overlay” list of ignored CVEs and have the tracker merge this list with Debian’s one. See the usage info provided by Bastian when he shared the patch.

#12 Updated by intrigeri 2018-03-28 19:15:36

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

#13 Updated by intrigeri 2018-06-12 06:44:56

intrigeri wrote:
> The attached patch (from Bastian Blank <waldi@debian.org>) might allow us to maintain our own “overlay” list of ignored CVEs and have the tracker merge this list with Debian’s one. See the usage info provided by Bastian when he shared the patch.

This was improved, merged, and is used by the Extended LTS security tracker :)

#14 Updated by intrigeri 2018-08-20 10:11:53

  • Target version deleted (Tails_3.10.1)

Let’s see what we decide at the summit.

#15 Updated by intrigeri 2018-12-02 22:11:12

  • Subject changed from Simulate tracking of security updates on a frozen Buster stable branch between Buster sprint #1 and #2 to Simulate tracking of security updates on a branch based on snapshots of Debian testing
  • Assignee deleted (intrigeri)

#16 Updated by intrigeri 2019-08-30 20:17:45

  • Status changed from In Progress to Confirmed