Hi,
Rene Engelhard:
> On Mon, Feb 26, 2018 at 06:43:18PM +0100, Olivier Tilloy wrote:
>> oSoMoN: but, complain mode may be noisy for people who
>> don't care about apparmor
>> oSoMoN: so, the idea is, in Ubuntu, if the profile is good
>> enough to use in the default install of the package, it is enforce. if
>> the profile can't really be turned on by default for *reasons* (eg,
>> firefox, libreoffice), ship it disabled
>> oSoMoN: if the profile is installed via some other means
>> and is 'in progress', eg, apparmor-profiles, then install in complain
>> mode
> And the profile here IS in-progress. Or why do we constantly find new
> stuff which needs to be fixed? :)
> And disabling it would hide it alltogether and bugs like
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887593 wouldn't even
> be filed, thus not knowing what to do until it breaks for users as it
> happened for your 5.4.5 packages (and our 5.4.3 packages)
> There also is still stuff hidden by complain that would break if it's in
> enforce. […]
As far as the Debian Buster development cycle is concerned I propose:
1. Ship the profiles that are WIP but not too bad already in enforce
mode until the Buster freeze, so that we learn about remaining
issues, have a chance to fix them and to draw a conclusion based on
actual data later on (see below).
2. Around the Buster freeze, look at how the rate of bug reports has
evolved and decide what to do for Buster based on that. E.g.
say there's been no new bug report about these profiles since
3 months, and the remaining known issues are acceptable, ship them
enforced in Buster; otherwise, disable them by default in Buster.
3. Anyone importing/backporting the package from testing/sid (e.g.
uploaders to stretch-backports, Ubuntu maintainers) shall make
their own informed decision. In most cases it's probably a good
idea to disable the AppArmor profiles in backports and stable
distro releases until we reach a decision on #2.
Cheers,
--
intrigeri
