[pkg-apparmor] Let's enable AppArmor by default (why not?)

[intrigeri]

Hi,

a year ago, on August 4 2017, intrigeri wrote:
> tl;dr: I hereby propose we enable AppArmor by default in testing/sid,
> and decide one year later if we want to keep it this way in the
> Buster release.

Here are some data points relevant to this decision making process.
I think we're in a good place to make a decision in November 2018
as planned.

> A proposal
> ==========

> 1. Enable AppArmor by default in testing/sid as soon as feasible in
>    the Buster cycle. […]

AppArmor was enabled by default in November 2017 in our kernel in sid
and the change quickly propagated to testing.

> 2. During a year, watch out for AppArmor related issues and address
>    them in a prompt manner. […]

This happened. See latency stats below.

> 3. A year after AppArmor was enabled by default: evaluate how it went
>    and decide if Buster should be shipped with AppArmor enabled by
>    default or not.

As part of this evaluation process, see the report of the BoF we've
hosted on this topic at DebConf18:
https://people.debian.org/~intrigeri/blog/posts/Report:_AppArmor_BoF_at_DebConf18/

Next step for the AppArmor team: compile the list of remaining issues
we consider as blockers and ensure they're fixed before Buster
is frozen.

>    I commit to do an analysis using BTS data to help make this
>    decision.

AFAICT the BTS currently has very few bugs opened that are caused by
AppArmor and have no patch attached. If the ones you care are not
on our radar, see https://wiki.debian.org/AppArmor/Reportbug#Usertags.

I've analyzed how the AppArmor team has performed once a given bug
appeared on our radar (with the documented usertags) between
2017-08-01 and 2018-08-04, inclusive. tl;dr:

 - 47 bugs were tagged since 2017-08-01 (not counting duplicates);
   I suspect quite a few more issues were not usertagged and are
   therefore not accounted for in my stats; I hope this means the
   maintainer of the affected packages could solve the problem
   themselves somehow;

 - in the vast majority of the cases, the AppArmor team sent a first
   reply on the very day the bug popped up on our radar;

 - in 75% of the cases, a solution was proposed within 8 days once
   the bug was brought to our attention.

See the attached stats.mdwn for details if you're into things like
standard deviation :)

reportbug 7.1.8+ reports the enabled LSM so we could compute the
ratio of testing/sid users who opted-out from AppArmor. I doubt
that spending time on it would be the best use of my Debian time
but if you folks feel it's needed to make a decision, I'll do it.

> Here's what popcon says ("Vote" count) for the apparmor binary
> package, that's needed to use AppArmor:

>  * 2015-01:  ~400
>  * 2016-01:  ~700 (+75% in a year)
>  * 2017-01: ~1300 (+85% in a year)
>  * today:    1870 (+44% in 7 months)
     ^^ i.e. 2017-08-04

Update:

   * 2018-08-04 12986 (+594% in a year)
     … presumably because linux-image-* now "Recommends: apparmor".

Cheers,
-- 
intrigeri

-------------- next part --------------
A non-text attachment was scrubbed...
Name: stats.mdwn
Type: text/markdown
Size: 882 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-apparmor-team/attachments/20180804/8974c5ec/attachment.md>