[apparmor] [RFC] Refactoring apparmor-profiles repository

[Vincas Dargis]

Hi,

I would like to suggest to change how apparmor-profiles [0] repository 
structure looks, how versioning works.

Currently, we have ubuntu/18.10 directory [1] for the latest profile 
versions, but this naming/versioning scheme is not 
informative/transparent or useful enough.

Ubuntu 18.10 is under development, and it is not clear if it will have 
AppArmor 4.13 or not? Meaning, should developer use new dri-enumerate 
abstraction (available in AppArmor 4.13 [2]) for improving 
ubuntu/18.10/* profiles or should it backport it's rules inline? If it 
would be known that Ubuntu 18.10 will not have AppArmor 4.13, what if 
someone from OpenSUSE Tumbleweed would like to introduce new profile 
with 4.13 features? It can't go into ubuntu/18.10...

To make this better, apparmor-profiles repository could be refactored by 
creating new directory tree, copying current ubuntu/x.y into 
apaprmor/a.b, where A is major, B is minor AppArmor version number.

So,
ubuntu/18.10 would be copied (moved?) into apparmor/4.13
ubuntu/18.04 -> apparmor/4.12
ubuntu/17.10 -> apparmor/4.11
ubuntu/17.04 -> ignore or apparmor/4.10? *
ubuntu/16.04 -> apparmor/4.10 or ignore if 17.04 dir is used instead. *
ubuntu/15.10 -> apparmor/4.9 (for Debian Jessie LTS)

* - if Ubuntu 17.04 used AppArmor 4.10 too as in Xenial (16.04), it 
could be considered as more recent directory to be used (ubuntu/16.04 
ignored). I don't know which version it was, there's no entry for that 
release in http://packages.ubuntu.com.

I doubt this refactoring should "care" below ubuntu/15.10->4.9. AppArmor 
4.9 is used in Debian Jessie which is LTS right now, so it would be 
actually useful to have 15.10->4.9 transformation, especially as this 
distribution might still receive Thunderbird update, for example. If any 
other distribution might need older directories, that's no problem to 
create more.

Once this is in effect, downstream package maintainers could use 
profiles from the directory that reflects AppArmor used. This would 
allow to manage new feature inclusion in profiles in more 
straightforward way. I could, for example, start working on making 
Thunderbird profile more customizable with `#include if exists` in 
apparmor/4.13 directory, while backporting any other relevant fixes to 
4.12 down to 4.9 (4.9 cannot use variable in profile name, so 
backporting is needed, see [3] as example). This can be done today too 
of course, but current Ubuntu-based versions just uses additional 
Brain-cycles, opaques view, and so demotivates.

If it's ACK for the idea, there's one more question about implementing 
it, i.e. should it be copy or rename? I would got for copy, leaving all 
that exists as flat archive.

[0] https://gitlab.com/apparmor/apparmor-profiles
[1] https://gitlab.com/apparmor/apparmor-profiles/tree/master/ubuntu/18.10
[2] 
https://gitlab.com/apparmor/apparmor/blob/apparmor-2.13/profiles/apparmor.d/abstractions/dri-enumerate
[3] https://salsa.debian.org/mozilla-team/thunderbird/merge_requests/1/diffs