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
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
