Hi, Rene Engelhard: > On Mon, Feb 26, 2018 at 06:43:18PM +0100, Olivier Tilloy wrote: >> <jdstrand> oSoMoN: but, complain mode may be noisy for people who >> don't care about apparmor >> <jdstrand> 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 >> <jdstrand> 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