[apparmor] Packaging of Profiles

[Seth Arnold]

" do not agree. This is not 'breakage'. One, there shouldn't that many
people affected if the policy is good enough and two, the user will get
prompted on upgrade, yes, but upgrades happen seldom for regular users."

You must not have local changes in your firefox config. :)

Try this experiment: take an older firefox install, and modify the profile to forbid all Ux access. Remove all the text-editor business. Remove the mail and terminal business. Confine flash. (60÷ of why firefox needs a profile in the first place.) Then upgrade firefox through three or four versions, trying to keep things tight while still integrating changes for e.g. Openjdk and sun jre.

You'll probably get tired of reading a ~sixty-line diff to find the one change in the profile. And you'll probably want a three-way merge to show you only what changed in the most recent upgrade, not where the profile differs from your existing profile.

Honestly, I'd be happy if I could easily tell dpkg to never write into /etc/apparmor.d/ and put the updated profiles in /usr/lib/ somewhere. I guess I could take the time to learn how to modify my dpkg-config settings to always prefer my files, and just clean up all the .dpkg-new files periodically, but I can't be the only one annoyed at distro-provided profile updates.

We tried something isomorphic to the local/ directory a few years ago, and hated it. It was my idea, my implementation, and I came to detest it.

I don't want another band-aid. Your profiles make sense for the distribution as a whole: they are safer than nothing, but not tight enough for me, not even close. But I still want to see what's new in your profiles.

Hence, storing profiles in /usr/lib, copying them over when a user wants one, and 3-way merging with them. Much nicer. New porcelain over git for apparmor.d also seems like a much nicer profile repository implementation, it could be leveraged for distro updates too, but I 100÷ agree on VCS-in-VCS hell avoidance.

Thanks