** Description changed: FFe paperwork still in progress 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 incrementally update to it to test the new features that are available now and make the overall experience better tested and less disruptive. The release is primarily incremental improvements in the parser, libapparmor, userspace tooling and policy improvements and 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 * /etc/apparmor.d/cache is moved 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) Debian has been very active in improving the packaging since the plan is to release with AppArmor by default in Buster. 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). 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 and software - with apparmor integration continue to work (snapd, lxc, lxd, libvirt, - docker, etc). + 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). 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: In Progress Bug description: FFe paperwork still in progress 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 incrementally update to it to test the new features that are available now and make the overall experience better tested and less disruptive. The release is primarily incremental improvements in the parser, libapparmor, userspace tooling and policy improvements and 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 * /etc/apparmor.d/cache is moved 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) Debian has been very active in improving the packaging since the plan is to release with AppArmor by default in Buster. 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). 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). 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
