Fwd: Re: Bug#855346: thunderbird: Can't open attachments with AppArmor profile enforced

[intrigeri]

Hi!

Mike Hommey:
> On Sat, Oct 28, 2017 at 02:10:43PM +0200, Carsten Schoenert wrote:
>> I forward this to the pkg-mozilla maintainer list, hopefully one of the
>> other admins of this alioth group can help out here, it's currently a
>> mess to coordinate the work! Thanks.

> Sorry. Somehow I missed all the messages up to this one.

Oops.

> Although I don't get it... why is it not in apparmor-profiles, like firefox?

Just to be clear: is this blocking me getting access to thunderbird.git?

Regardless, thanks for asking.

There are quite a few reasons why it's deemed better in practice — by
the AppArmor community and distro integrators who enable AppArmor
already — to ship AppArmor policy along with the software it confines.
This conclusion comes from years of actual experience using both
approaches in parallel. I'm happy to explain some of the reasons
behind it.

For example, one of these reasons is about backports (and security
updates when they're really backports, as is the case for
Thunderbird): if we shipped policy elsewhere (e.g.
in apparmor-profiles*), then when a user upgrades to the latest
Thunderbird, in most cases they'll still be using AppArmor policy that
was created for an older version of Thunderbird, which has
non-negligible potential to break the software. This can make user
experience poor or make the maintainers' life more painful as they
have to test & support more combinations of (software version, policy
version). Think of it as a configuration file that directly affects
the behavior of software X: if we shipped it outside of package X,
then we would have to maintain strict versioned dependencies and spent
quite some time reasoning about which combination can actually work.

Granted, in some cases we're still using the other approach:
apparmor-profiles and apparmor-profiles-extra ship a few
AppArmor profiles. The former is a problem (being discussed on
#830502) and the latter is meant to be a staging area used until
profiles are good enough to be shipped with the software they confine.

And granted, the "ship policy with the software it's about" approach
also has its own downsides (e.g. load of buildds if we need to do an
additional Thunderbird upload just to fix a bug in its AppArmor
policy; or the fact this requires good communication between AppArmor
people and package maintainers, which has both advantages and
drawbacks). But all things considered, these downsides simply don't
weigh enough make us prefer doing things differently.

(And wrt. Firefox: this is not a very relevant example for the
discussion at hand as it is shipped in /usr/share/doc, in a directory
whose README clearly states it's not mature; it's not enabled
by default.)

I hope this makes things clearer. If not, don't hesitate asking :)

Cheers!