Re: recommends for apparmor in newest linux-image-4.13
Hi Michael,
Michael Stone:
> FWIW, I also think apparmor a bad idea,
For me it's good news: if you explain why (please?), it will furnish
nutrient to this discussion and we'll be in a better position to make
the best decision we can for our users and free software :)
> but it's somehow morphed from "can we make it possible to turn
> apparmor on" to "let's make RC bugs for stuff that doesn't work with
> apparmor" without much real buy-in AFAICT.
Regarding "can we make it possible to turn apparmor on": this has been
possible for years and was announced on d-d-a@ 2.5 years ago. This is
*not* what the proposal I've sent in August was about: that one was
explicitly about enabling AppArmor by default. If you're suggesting
there's been a decision making process mishap, then I'll need to be
explained why, because I don't get it.
Regarding "without much real buy-in": even though I believe we've
reached consensus on my proposal between August and October (as Ian
Jackson explained last week on this mailing list), I agree with you on
this one. This proposal did not trigger an overwhelming wave of
enthusiastic support. We don't make decisions by public acclamation
here but still, it's an important data point and IMO it implicitly
raises the bar wrt. how good our AppArmor support must be in order to
be acceptable by the project.
Regarding RC bugs: I don't think breakage that only happens with
AppArmor enabled should be RC in the context of the experiment we're
currently running: in the vast majority of cases, a local workaround
is available (one can disable the faulty AppArmor profile with the
aa-disable command). If we decide to leave AppArmor enabled by default
in Buster we should reconsider this though. Regardless of bug
severity, I want to keep fixing these bugs. If you need help with
AppArmor-related issues, you can ensure they're on pkg-apparmor-team's
radar this way:
https://wiki.debian.org/AppArmor/Reportbug#Usertags
Cheers,
--
intrigeri
Reply to: