[apparmor] [pkg-aa-profiles-team] License and copyright of ~apparmor-dev/apparmor-profiles?

Wed Aug 20 21:54:21 UTC 2014

On 08/20/2014 04:06 AM, intrigeri wrote:
> Hi,
> 
Hi!

> [re-adding pkg-aa-profiles-team@ into the loop, as I suspect that at
> least Holger doesn't read the AppArmor ML yet.]
> 
> Jamie Strandboge wrote (20 Aug 2014 03:46:57 GMT) :
>> What package is being uploaded? Is this a separate apparmor policy package from
>> the apparmor source package itself?
> 
> Yes. It's called apparmor-profiles-extra. It's waiting in the NEW
> queue, and we won't nag ftp-masters about it until the copyright and
> license have been clarified upstream.
> 
>> If so (and forgive me if I am misinterpreting-- I'd just like to make sure that
>> this is discussed here),
> 
> Well... it's been discussed here a bit a while ago already.
> 
> I won't have time to reply in depth to the rest of your email before
> DebConf, but I kindly invite you to re-read the email I've sent to
> this very mailing-list 1.5 years ago:
> 
>   https://lists.ubuntu.com/archives/apparmor/2014-January/004876.html
> 
> In there, I explained my rationale for going this way, and was seeking
> for feedback. You replied to that email "I'd recommend that the
> apparmor-profiles-extra package be a separate source package in
> Debian". This is exactly what we've been working on since then.
> 
Well, a year and a half is a long time, and I've had some time to think about
this more.

> So, while the longer-term cross-distro collaboration plans can surely
> be rediscussed, and are being rediscussed, I think that it's way too
> late, in this Debian release cycle, to revisit the decision of
> shipping a few additional profiles in a separate package in Jessie, as
> opposed to adding them into the individual affected packages.
> 
> Note that there are currently 4 profiles in the proposed package.
> 
>  * 2 of them (irssi, Pidgin) come straight from the apparmor-profiles
>    repo; the irssi one will likely be moved to the irssi package
>    before the Jessie freeze (yeah, we're also trying to go this way
>    when the maintainer is OK with it);
>  * 2 of them (Evince, tcpdump) come from individual Ubuntu packages.
> 
> I want to add the Totem profile from apparmor-profiles before the
> freeze. I think that's all what we're gonna ship in there in Jessie,
> so if it's really problematic, then the problem is quite small,
> localized, and easy to fix if we change strategy :)
> 

Ok, with only 4-5 profiles in place, I don't see this as a major collaboration
problem or anything and I agree this makes sense for Jessie. (also see my
response to myself for how we can maybe do both the apparmor-profiles-extra
package and pushing into the packages themselves)

>> Ubuntu has already pushed policy into Debian packages somewhat, but there is
>> more to be done.
> 
> I *don't* want to throw stones at anyone, but I've seen very little
> progress on this front since I'm involved in AppArmor. I think
> a reality check is warranted, to make sure that we're speaking of the
> same thing.

Sure. If I wasn't clear, I am taking the position that Ubuntu can and should be
doing better wrt to this.

Historically, Debian took the position that it would not carry distro patches
for AppArmor while Ubuntu would (eg, the compat patchset). This limited the
collaboration in some ways for some time.

Much more recently, specifically the last year and a half, AppArmor development
has accelerated greatly and Ubuntu could in many ways be considered as the test
bed for the work the AppArmor team wants to upstream (eg, dbus, signals, ptrace,
and the upcoming anonymous and abstract socket mediation). This work required a
*substantial* rewrite to the base labeling. Ubuntu and in particular the
AppArmor developers have an overarching goal to push everything upstream and we
have been upstreaming parts of this work where we could (eg, dbus and notice
that the compat patchset that Ubuntu carries is considerably smaller than it
used to be), however, due to the nature of the rewrite and how intertwined all
the IPC work is (not to mention the namespace work that has been happening in
parallel), much of this work has not been in upstreamable form since it wasn't
complete (note, we've been writing it in an upstreamable way-- it just wasn't
ready).

Once the anonymous and abstract sockets work is completed, we should be able to
upstream much of the aforementioned work. In the coming months we plan to
improve systemd support and work on fine-grained network mediation which when
accepted upstream should allow the compat patch to finally go away entirely. (We
also plan to finish the stacked policy (aka namespace) work too.). All of this
will allow us to align and more meaningfully collaborate on policy.

I mention all this to provide some context-- the laser focus on this feature
work in combination with Debian's kernel policies has unfortunately lead to less
than optimal collaboration between Debian and Ubuntu. We can work together to
change this though! :)

> Here's the full list of profiles that landed from Ubuntu
> in the Jessie release cycle, as far as I know:
> 
>   * bind9: I thinks this one truly was pushed by Ubuntu, thanks to the
>     package being collaboratively maintained between our two distros :)
>   * cups: I had the profiles (trivially) enabled in the Debian package
>     (Debian#735313); all it took was dropping a "if Ubuntu".
>   * mysql-5.5: I nagged people into removing the "if Ubuntu" bits
>     (Debian#736087), and then Ubuntu folks did most of the work.
>   * libvirt, mostly thanks to Felix Geyer for pushing/adapting things.
>     I'm now nagging the people who introduced the Ubuntu delta into
>     pushing it into Debian.
>   * LXC profiles from upstream (i.e. mostly Ubuntu): can't work in
>     a distro that doesn't patch the kernel heavily, as it relies on
>     dbus, signal, ptrace and mount rules.
>   * lightdm profiles from upstream (i.g. mostly Ubuntu): the Debian
>     maintainer initially included it as-is, but they didn't parse
>     since they relied on newer AppArmor features; I had to fix it.
> 
> So, sure enough, stuff did come in, but that's not exactly what
> I would call "Ubuntu pushing policy into Debian". I hope you can now
> better see from what perspective I'm looking at these things :)
> 

libvirt and LXC are probably the two most difficult examples for various
reasons. Also, as you pointed out, our kernels are quite different which can be
a pain point. That said, after going through the updates for dbus, signals,
ptrace and now abstract and anonymous sockets, we can hide a lot of our
differences in the abstractions (even now).

Unfortunately I won't be at DebConf, but I know other members of the AppArmor
team from Ubuntu are looking forward to meeting with all of you.

> Anyway: thanks for your work, no bad feelings here.
>
None here either. My sincere hope (and plan!) is for the Ubuntu and Debian
AppArmor teams to be able to move forward and make real progress on
collaborating now that many of the hurdles are (coming) down.

Thanks!

-- 
Jamie Strandboge                 http://www.ubuntu.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20140820/86684af9/attachment.pgp>