Feature #12615: Consider basing Tails on quarterly snapshots of Debian testing
Simulate tracking of security updates on a frozen Buster stable branch between Buster sprint #1 and #2
- 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 email@example.com:secure-testing
IMO it's too early for a 2nd person to invest time learning how to use the thing.
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.
- % 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.
Today I would want to:
- upload wget (https://www.debian.org/security/2017/dsa-4008)
- look closer at the xorg-xserver issues
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).