On 2/10/25 03:48, intrigeri wrote:
Hi,
Hey, nice to hear from you
Long time no see, I hope you're doing good! Currently Debian testing/sid is tracking AppArmor 3.1.x. I'm wondering if I should upgrade to 4.x for Debian 13 (Trixie), whose freeze will start in a few months. I would greatly appreciate some advice.
Yes. We have been planning to get debian updated to 4.1. Beta4 should be dropping some time today. We still have a couple of known issues to fix before finally release but it is getting close. It should release some time this month (February). 4.1 will be a long term support version, where the current 4.0 release was not. Our next planned release will be 5.0 and that will enter beta some time this fall with a release early next year.
https://apparmor.net/news/release-4.0.0-alpha1/ suggests I should wait for 4.1 which "is planned to be a regular release". I see Ubuntu is now shipping 4.1 betas. Is there a timeline for 4.1 final?
September 2024 :) This one has been a real pita, with lots of bugs to work out and some additions that have had to come during the beta cycle, like python 3.13 changes broke several things. We have also pulled in things during the beta that maybe we shouldn't have like support for spread testing. This has certainly delayed the final release but we think the additional testing support is going to be worth it long term, especially on an LTS release.
Do I understand correctly that 4.x (or is it only 4.1?) may not support policy that was written for 3.x?
AppArmor 4.x is backwards compatible with 3.x through the abi mechanism. If a profile declares support for a 3.x abi that is what will be supported and used. AppArmor 3.x is only partially compatible with apparmor 4.x policy. If policy declares a 4.x abi, apparmor 3.x will try to support it to the best of its ability, but there are some things it won't know about, and if the 4.x policy uses policy features (keywords etc) that AppArmor 3.x doesn't know the policy will fail to compile. AppArmor 4.x supports having AppArmor 2.x, 3.x, and 4.x policy intermixed on the system. So you don't have to have a monotonic policy update. The kernel side of this abi support feature is used by LXD to run say an Ubuntu 20.04 container with its expected policy on a host that has different support. There is a caveat to the whole non-monotonic policy update in that profile interactions may force some updates to happen together. ie. If a profile now says it expects NetworkManager to be confined before allowing the application to talk to it, and old policy didn't have NetworkManager confined there would need to be something done to address the issues (either making sure Policy ships with a NetworkManager profile, or adjusting the profile that is forcing that dependency change).
