FYI, disco now has 2.38 (I've updated the description accordingly). ** Description changed:
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 should be uploaded to Disco very - soon (I'm told this week or early next). 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). + 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 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1817799 Title: [FFe] apparmor 2.13 Status in apparmor package in Ubuntu: New Bug description: 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1817799/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
