On 2017-07-04 09:52:55, intrigeri wrote:
> Hi,
>
> intrig...@debian.org:
>> The apparmor-profiles package ships a number of profiles in
>> /etc/apparmor.d/, "in complain mode so that users can test and choose
>> which are desired". This includes policy for dovecot, dnsmasq,
>> avahi-daemon, ping.
>
>> This is confusing to some of us, and to users in general. And IIRC
>> Felix had some concerns about shipping these profiles there as well.
>
>> During the team meeting we had at DebConf, several options were
>> suggested:
>
>> a) Move the profiles that are not good enough to be enforced to
>> a separate package
>
>> b) Move the profiles that are not good enough to be enforced to
>> /usr/share/doc (where we already ship a number of profiles)
>
>> Also, it might be that some of these profiles are actually good enough
>> to be enforced by default, instead of being moved elsewhere.
>
> I'm adding Antoine in the loop as he suggested on
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866790#19 that we do the
> opposite,
> i.e. to ship profiles from /usr/share/doc/apparmor-profiles/extras/ in
> /etc/apparmor.d/ in complain mode. It seems we have good reasons to
> move policy that's not quite ready for production use out of
> /etc/apparmor.d/ (this is what this bug was about originally), but we
> also have good reasons to do the exact opposite.
>
> Advantages of shipping not-quite-ready-yet profiles (in complain mode)
> in /etc/apparmor.d/:
>
> * users who want to use some of these profiles simply have to
> aa-enforce them, and they'll automatically get updated versions
> when they upgrade apparmor-profiles; FTR the current situation is
> that these users *copy* those profiles to /etc and then report bugs
> about their obsolete copy (e.g. #866790), which is confusing to
> users and adds extra maintenance workload on our team;
>
> * giving these profiles more exposure to testing might encourage some
> users to improve them upstream.
>
> Drawbacks of shipping not-quite-ready-yet profiles (in complain mode)
> in /etc/apparmor.d/:
>
> * it's hard to communicate to users the quality of these profiles,
> and where bugs/improvements shall be submitted; currently we have
> /usr/share/doc/apparmor-profiles/extras/README that states clearly
> that these profiles "are not as mature as the profiles in
> /etc/apparmor.d/", and that improvements shall be submitted
> directly upstream. If we were shipping these profiles in /etc, I'm
> worried we would get even more bug reports about them in the Debian
> BTS, which causes 1. extra workload on our team; 2. frustration for
> the user (being redirected to yet another BTS after reporting a bug
> discourages many people, while perhaps they would send their
> proposed changes directly upstream if instructed to do so in the
> first place)
My counter-argument here would be that I would *assume* a profile in
"complain" mode is not production ready, by definition.
The problem with people filing bugs directly in the BTS is a false
problem, in my opinion: you'll always get this, regardless of how you
set things up. Obfuscating the profiles in /usr/share hasn't helped you
with my bug report, and I consider myself a rather experienced user. I
even *knew* about that policy before and *read* that README file, all
the way back when I deployed those profiles, and I simply forgot about it.
A more productive way of pre-triaging bug reports is with reportbug
hooks, to make sure users are made aware, when reporting bugs, what they
should report upstream. For example, the file
"/usr/share/bug/$package/presubj" is shown to the user before asking for
the subject. You can even interactively prompt the user for stuff... See
the docs here for details:
/usr/share/doc/reportbug/README.developers.gz
Such a prompt would have certainly given me pause when reporting a bug
against apparmor-profiles-extra...
In other words, I think shipping profiles in /usr/share is the wrong
solution to this problem. Proper packaging of those profiles should
install them in /etc/apparmor.d, otherwise they do not bring a
significant enough advantage for me to use them over directly getting
them from upstream (other than the maintainers' verification and trust
path, naturally). Bug pre-triaging problems can be solved in other ways.
Thanks!
A.
--
Nothing in life is to be feared, it is only to be understood
Now is the time to understand more, so that we may fear less.
- Marie Curie
