intrig...@debian.org: > Package: apparmor > Version: 2.11.0-11 > Severity: important
> My plan is: > 1. in testing/sid, ship a conffile (in a package built from > src:apparmor) that pins the most recent feature set fully supported > by our policy, i.e. Linux 4.12's or 4.13's (depending on whether > we've fixed all the regressions brought by 4.13 yet); this should > make the transition to Linux 4.14 smooth; > 2. once our policy has been updated to work well with Linux 4.14's > AppArmor features (#877581), bump the pinned feature set to 4.14's I'll need to test what happens when upgrading the feature set file + Linux in lockstep, when the new feature set includes features brought by the Linux upgrade and not supported by the running kernel. This will happens when upgrading to the next Debian stable, or on a rarely upgraded testing/sid system. It'll be solved on reboot but I want to ensure the package upgrade succeeds. A special case of this general problem is when one intentionally runs an older kernel than the one whose feature set we've pinned. I did not test this yet. My understanding is that the worst that can happens is that one gets no AppArmor confinement at all, which is not exactly a regression compared to what Debian has been doing so far, and it's a corner case so I won't treat this as a blocker.