Hi Reiner,
Reiner Herrmann:
> thank you for your surf patches!
My pleasure :)
> I'm a bit hesitant to introduce a new binary package for the AppArmor
> profile.
Understood, I'm too.
> What do you think about dropping/commenting the gstreamer part of the
> profile, so there is no longer a dependency to apparmor-profiles-extra.
> This would break some sites with multimedia content when AppArmor is
> enabled, but could also be re-enabled by the user if required.
FYI this approach kinda conflicts with the strategy we've been
following so far with AppArmor in Debian, i.e. essentially "only
enforce by default policy that does not break the confined software".
The rationale behind this strategy is: if a user perceives that
"AppArmor breaks software X", there's a good chance they fully disable
AppArmor on the affected system, possibly even on all their future
systems, and start advertising "disable AppArmor" as a potential
solution to all kind of (possibly unrelated) problems on public fora.
I've seen this happen for SELinux and I've been doing everything
I could to avoid this happening with AppArmor.
Re-enabling specific bits of policy requires learning about AppArmor,
where the policy lives, what's the best way to edit it, how to reload
it. Having to do that merely to have a browser support YouTube and
alike feels like too big a hurdle for users, no? Now, I don't know
much about surf, its users and their expectations. I know that surf is
advertised as "simple", but it's not described as "minimalistic" or
with a restricted set of functionality.
> Or as an alternative (that I would prefer) to merge the content from
> abstractions/gstreamer into the surf profile?
Such duplication is generally frowned upon for good reasons: one has
to maintain the same information in one more place. Now, since the
GStreamer abstraction was added to Debian four years ago, it has been
updated only 3 times, so perhaps in this case it's not such a big deal.
Still, I'm not sure I see the benefit: both options I see on the table
("keep the dependency on apparmor-profiles-extra" and "import a copy
of abstractions/gstreamer into the surf profile") require some amount
of communication and coordination between us; that is, with the
duplication way, whenever we apply important fixes to the GStreamer
abstraction, you'll need to learn about it somehow so you can update
the copy accordingly. As you can see, I'm ready to do my part of this
coordination work, so personally I'm not worried about keeping the
current dependency in place :)
Anyway, I can live with both options. If you decide to ship your own
copy of the gstreamer abstraction, I suggest you do the following:
- do not inline it in usr.bin.surf; instead, ship it in
abstractions/surf-gstreamer and include it from usr.bin.surf
- set up a CI job (possibly an autopkgtest) that compares your copy
of the GStreamer abstraction with the one shipped by current
apparmor-profiles-extra and raises a visible warning when they
differ
Cheers,
--
intrigeri
