[apparmor] Sharing profiles maintenance once they're ready for production

[John Johansen]

On 03/10/2014 02:06 PM, Christian Boltz wrote:
> Hello,
> 
> Am Freitag, 17. Januar 2014 schrieb intrigeri:
>> 1. I've little experience maintaining profiles in a cross-distro way,
>>    but I suspect that tunables should be enough to cope with most
>>    distribution-specific deltas. What do you think?
> 
> I fully agree - having cross-distro profiles (if needed, with some 
> differences in tunables) sounds like a good goal.
> 
>> 2. Was this discussed previously? Was the idea of a cross-distro VCS
>>    repository for shared maintenance of profiles investigated yet?
> 
> It was discussed, but without a real solution.
> 
> As you already noticed, there's lp:apparmor-profiles, and the way it is 
> handled makes it quite (and IMHO needlessly) hard to share the profile 
> with other distributions.
> 
yes, it was supposed to be the first step in getting something better
but it really hasn't achieved that

> For openSUSE, I package only the profiles in lp:apparmor, and submit my 
> changes back to lp:apparmor. This means the profiles shipped in the 
> AppArmor tarball will always work on openSUSE [1], but it also means I 
> don't have lots of profiles to ship.
> 
yep, unfortunately

> Some openSUSE packages also contain their own profile, but I don't have 
> a good overview which packages contain profiles. Those profiles are 
> usually maintained by the package maintainer.
> 
It would also be nice if we could loosely track those. The maintainer
may not want to deal with our tracking of them but it would be well worth
adding them with annotations.

> This also opens up an important question: who does the profile 
> maintenance?
It depends

> - If the packager does it, then it's understandable that he wants to 
>   have the profile in his package, which also makes it easy for him to 
>   update it. (Ideally the profile would be in $package's upstream 
>   tarball, but this rarely happens.)
right, and even if it does a distro may want to track modifications to it.

> - If $package maintainer doesn't care and bugreports about the profiles 
>   end up at the AppArmor packager, then having the profiles in the 
>   apparmor-profiles package (and in lp:apparmor) is the best solution.
>   This also tends to be a fast and efficient way - if you avoid sending 
>   20 profile patches per day, you'll usually get a review within some 
>   days ;-)
> 
> That all said: Yes, I'd really like to have a better way to share 
> profiles with other distributions. We "just" need to decide about the 
> method ;-)
> 
> I'd be happy with adding profiles to lp:apparmor/profiles/apparmor.d/ -
> any other opinions?
> 
Its not sufficient. It would be nice if we could track distro branches
and merge them back and forth easily. Some distros want to ship different
sets of active and reference profiles etc. I think the current split
between lp:apparmor-profiles and lp:apparmor/profiles/apparmor.d/
is problematic and we really should split profiles out of the tools
package, so its all in one place.

Its certainly possible to we could run multiple branches of
lp:apparmor-profiles, a main one and distro branches. And come up with
a work flow around that.

I know the idea behind having a single repo was that everything should
be feeding back into the main repo. I think in general we do want that
but its too simple. With profiles we have dependencies on different
userspaces, different versions of different programs, different kernels
all of which can affect profiles.

The upstream main repo for profiles really needs to track different
releases, and accumulate as much as makes sense from distros. I think
distros need to be able to commit their own changes back without
the issues of merging into the main repo. Of course distro may want
to track their own profile changes in something other than lp/bzr
but we atm there is only so much we can do/support.

It would be great if the main repo could know about distro/alternate
repos and automatically detect changes in them for review. It would
also be good if we had tools to help with all of this.