Feature Freeze exception for AppArmor 2.13.2
The security team is pushing to get AppArmor 2.13 into 19.04 since we want AppArmor 3 (or higher) in 20.04 and we'd like to update to 2.13.2 to have widespread use of its new features and make the overall experience to AppArmor 3 better tested and less disruptive.
The 2.13.2 series over 2.12 is primarily incremental improvements in the parser, libapparmor, userspace tooling and policy; Debian started preparing 2.13 in experimental last June where the first upload to unstable was made in July. Since then, Debian has worked closely with upstream and Ubuntu devs to shake out bugs and improve the packaging. There are no new mediation rules so the chance of regression in terms of parser/kernel/policy updates is considered low.
IME, the primary points of interest for the FFe surround the following:
* apparmor_parser in 2.13 now creates subdirectories in the cache directory with the subdir name based on the kernel features. This improves the experience when booting between kernels with different feature sets
* Debian moved /etc/apparmor.d/cache to /var/cache/apparmor (first upload with this change in August)
* the init process now uses proper systemd unit instead of calling out to SysV init script. This and rc.apparmor.functions cleanups were done in coordination with Ubuntu devs (first upload in December)
* due to bug #1820068, the 2.12 and earlier Ubuntu-distro patch to use -O no-expr-simplify (helps with policy compilation times on armhf) has been reverted. We'll get the bug fixed before disco release
Debian has been very active in improving the packaging since the plan is to release with AppArmor by default in Buster (it has been on by default in Debian testing for a long time, before the 2.13 uploads). A version of 2.13.2 has been in Debian testing (Buster) since January with the 2.13.2-9 version that this FFe is based on migrating last week. Debian improved autopkgtests throughout Buster, worked with upstream and Ubuntu devs throughout.
Because of the extensive baking in Debian, I think it is reasonable to consider granting the exception (indeed, part of why we missed Disco's freeze was because we were working with Debian on improving the package for Buster's freeze).
While most software in Ubuntu doesn't care about the systemd or cache changes, it was known that snapd manages snap cache files on snap remove, and snapd needed to be changed to account for this[2]. This update is included in snapd 2.38 which is now in disco. Because of the change in the apparmor cache, I have introduced a Breaks: snapd (<< 2.38~) in the apparmor package since snaps cannot be removed (snapd aborts the removal when the cache file is not found; which is a little strict IMO, but I digress).
In terms of testing, we exercised our test plan, like normal[1]. This includes upgrade testing, verifying profile load on boot, cache is used and software with apparmor integration continue to work (snapd, lxc, lxd, libvirt, docker, etc). Anecdotally I have been using 2.13.2 for some time without issue (and I have a lot of snap, distro and personal policy).
The source tarball does not contain a changelog, instead the upstream release notes can be found here:
* https://gitlab.com/apparmor/apparmor/wikis/Release_Notes_2.13
* https://gitlab.com/apparmor/apparmor/wikis/Release_Notes_2.13.1
* https://gitlab.com/apparmor/apparmor/wikis/Release_Notes_2.13.2
[1]https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor
[2]https://github.com/snapcore/snapd/pull/6549
Here is the upgrade log. Note that these parser errors are unrelated to apparmor 2.13 and an issue with the snapd packaging:
AppArmor parser error for /etc/apparmor.d in /etc/apparmor.
AppArmor parser error for /etc/apparmor.