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) I have to say I'm torn between these two options. What do my fellow team-mates think? Cheers, -- intrigeri
