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

[Jamie Strandboge]

On 08/19/2014 10:46 PM, Jamie Strandboge wrote:
> On 08/19/2014 02:44 PM, Holger Levsen wrote:
...
> I understand the desire to ship policy in a single unified package
> (we've discussed this quite a bit in Ubuntu) because it can make it somewhat
> easier for the policy team, but I think shipping policy in the affected packages
> is a good thing for several reasons:
> 
>  * it keeps the Debian/Ubuntu developer and or team engaged with the policy
>    because they own it. With tools like dh_apparmor and new dh, it is trivial
>    to add policy to affected packages. These developers typically know the
>    package better than policy writers and are in a position to test the package
>    with new upstream releases and update the policy accordingly
>  * Bugs go against the package that is affected. Not only is this natural, in
>    practice, AppArmor is easy enough for regular people to use so the bugs are
>    often either of high quality (ie, contain a patch or policy snippets to fix
>    the bug) or are easy to understand for the developer to update the policy.
>    We use the 'apparmor' tag in Ubuntu to make it easy for policy authors to
>    find bugs related to apparmor policy. Debian could do something similar.
>  * It ensures there is no bottleneck for adding AppArmor to packages. Eg, a
>    Debian developer need only update his/her own package rather than trying to
>    maintain the policy in a package he/she does not own. It would be a shame
>    if a developer interested in increasing the security of his/her package by
>    adding Apparmor would give up because it is too difficult to maintain in a
>    foreign package. Considering Debian's strong package ownership compared to
>    Ubuntu, this is a real concern of mine
> 
A couple of other things I thought of last night:
 * When shipping in a package, ideally the package should support both complain
   and enforce mode for individual profiles so that installing it may enable
   enforcing policy (this isn't a collaboration concern, just a packaging one)
 * shipping all policy in one package means more is loaded and compiled than is
   strictly needed for the system
 * a collaboration option is to ship profile in the package, but file bugs
   against the source packages that are being confined (ideally with debdiffs to
   make it easy for the Debian developer to take it ;). This is a bit of best of
   both worlds-- the policy can still be developed by the policy team, but we
   give the developer the option to take over

-- 
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: <http://lists.alioth.debian.org/pipermail/pkg-aa-profiles-team/attachments/20140820/b03e4a25/attachment.sig>