Comment 14 for bug 1350598

A few things I neglected to mention that John reminded me of are

1. if the kernel changes its apparmor feature set or the apparmor parser itself changes how it generates policy, we'll still be running the old kernel and parser. This will happen on an upgrade from 15.04 to 16.04 for example. If the device tarball exported the apparmor feature set (it can be mocked as a text file-- we do that for custom tarballs already for example) then we can point the parser at that. Furthermore the parser could be extracted from the tarball as part of the recompile step.

Since most upgrades very-much-intentionally do not change the parser or the feature set, I think the first iteration could avoid dealing with the apparmor features file and the parser. The second iteration could incorporate it.

2. Due to how profile caching is currently implemented, the recompiling caches is a one way operation. In other words, if prior to reboot we recompile all the policy that invalidates the old caches. If on reboot the boot detects that a recompile is needed (eg, we got something wrong before reboot-- eg, the kernel in the device tarball was updated but someone forgot to update the mocked features file), then the recompile will still happen on reboot. If the processes surrounding updates are sufficient and QA is involved, this should be an avoidable situation.

3. The security team has worked on versioned policy caches in previous cycles but the work is incomplete and deprioritized. Depending on how things are ultimately implemented, its possible versioned policy caches could help with the implementation. I think performing point '8' on Touch and carefully handling the features file and parser changes, this is probably not needed (there isn't a concept of rolling back on Touch for example).