Bug#965360: apparmor-profiles: Please meke seperate packages for each apparmor profile
Control: tag -1 + wontfix Hi, … and sorry for the delay. Mikhail Morfikov (2020-10-24): > There are three ways of installing apparmor profiles in debian: > - an app's package contains some apparmor profile > - some packages contain lots of apparmor profiles > - there are a few packages which contain an app's apparmor profile itself, > for > instance fwknop-apparmor-profile > > So it's a mess. I understand this can be very confusing (I hope that's what you mean, expressed in terms of resulting impact, rather than in a judgmental manner). It's not news to me and I'm not surprised. In particular, the status of profiles shipped in the apparmor-profiles package often confuses folks (understandably!). As a result, the workload this package has required from me in the last years is disproportionately big, compared to its actual usefulness. I've tried to improve this in Bullseye by clarifying the package description, and including a reportbug script that asks users to report bugs upstream. If this is not enough to make users' expectations match our intent, or not enough to lower that workload, then I plan to stop maintaining the apparmor-profiles binary package in Debian myself. > It would be nice to have profiles in individual packages, so users > could decide what they want to install. Thanks for clarifying what use case is currently poorly supported. It seems to me that we want to optimize the user experience for different categories of users. The category of users I am primarily thinking about, when working on AppArmor support in Debian, are those who may not even know what AppArmor is, could not care less about whether profile X or Y is enforced, and certainly won't decide which profiles they want to install. I believe these are the vast majority of Debian users (and if that's not the case yet, then I prefer to work towards making this real). I'm happy to welcome contributions that improve UX for other categories of users, if this does not imply regressions for the aforementioned category. It does not look like your initial proposal achieves this, but perhaps a different proposal would :) >> Apart of this, the way the Debian archive works, having many tiny >> packages is problematic, so I don't think your proposal would be >> acceptable by the project. I'm not closing this bug report just yet as >> I'd like to first better understand what the current setup is lacking >> for you. > BTW: Why having many small packages is a problem for debian archive? This has been discussed several times on debian-devel@ so the answer can probably be found there. Cheers!
Bug#965360: apparmor-profiles: Please meke seperate packages for each apparmor profile
On 24/10/2020 14.42, intrigeri wrote: > Control: tag -1 + moreinfo > > Hi, > > Mikhail Morfikov (2020-07-20): >> currently when the apparmor-profiles package is installed, it installs >> several >> apparmor profile files. In this way users can have all or none of the >> profiles >> installed in their systems. Sometimes a user wants only a specific profile >> (or >> profiles) installed and doesn't really want the other profiles to be >> installed >> as well because: >> - he doesn't need the other profiles, >> - he has his own alternative profiles, which differ in rule sets, >> - the other profiles simply cause some issues with applications they >> confine. > >> What do you think about another approach, which is to create separate >> packages >> containing individual apparmor profiles? For instance, there's the >> usr.sbin.dnsmasq file which is related to the dnsmasq package. In this case >> there could be a package named dnsmasq-apparmor-profile which would include >> the >> usr.sbin.dnsmasq file. If a user wanted to install dnsmasq and also wanted it >> to be confined by the default apparmor profile provided by Debian, he could >> also install dnsmasq-apparmor-profile, which wouldn't affect any other app >> functionality. > > The profiles shipped by the apparmor-profiles package are installed in > complain mode. Then the user may choose to enforce the profiles they > need. To me, it seems to already provide the kind of flexibility > you're wishing for, with a much lower overhead on the package > maintenance side. What did I miss? > > Apart of this, the way the Debian archive works, having many tiny > packages is problematic, so I don't think your proposal would be > acceptable by the project. I'm not closing this bug report just yet as > I'd like to first better understand what the current setup is lacking > for you. > > Cheers! > There are three ways of installing apparmor profiles in debian: - an app's package contains some apparmor profile - some packages contain lots of apparmor profiles - there are a few packages which contain an app's apparmor profile itself, for instance fwknop-apparmor-profile So it's a mess. It would be better to have just one way of installing official debian apparmor profiles for apps, i.e. the 3rd option above. Of course a user doesn't have to install the big package with all the profiles, but when I see bunch of apparmor profiles that I don't really need, I simply skip the package or extract the needed profile and forget about the package. So basically having multiple profiles in one package makes people less likely to test any of the profiles included in it and hence less likely to report any issues. It would be nice to have profiles in individual packages, so users could decide what they want to install. What if I had my own profile that would match to a specific one that is provided by apparmor-profiles? What would I have to do in order to install/upgrade the rest of the profiles from the package and leave my profile intact? It's very inconvenient and problematic for the end user to handle such packages. BTW: Why having many small packages is a problem for debian archive? OpenPGP_0x32D9CB634796CCA1.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#965360: apparmor-profiles: Please meke seperate packages for each apparmor profile
Control: tag -1 + moreinfo Hi, Mikhail Morfikov (2020-07-20): > currently when the apparmor-profiles package is installed, it installs several > apparmor profile files. In this way users can have all or none of the profiles > installed in their systems. Sometimes a user wants only a specific profile (or > profiles) installed and doesn't really want the other profiles to be installed > as well because: > - he doesn't need the other profiles, > - he has his own alternative profiles, which differ in rule sets, > - the other profiles simply cause some issues with applications they confine. > What do you think about another approach, which is to create separate packages > containing individual apparmor profiles? For instance, there's the > usr.sbin.dnsmasq file which is related to the dnsmasq package. In this case > there could be a package named dnsmasq-apparmor-profile which would include > the > usr.sbin.dnsmasq file. If a user wanted to install dnsmasq and also wanted it > to be confined by the default apparmor profile provided by Debian, he could > also install dnsmasq-apparmor-profile, which wouldn't affect any other app > functionality. The profiles shipped by the apparmor-profiles package are installed in complain mode. Then the user may choose to enforce the profiles they need. To me, it seems to already provide the kind of flexibility you're wishing for, with a much lower overhead on the package maintenance side. What did I miss? Apart of this, the way the Debian archive works, having many tiny packages is problematic, so I don't think your proposal would be acceptable by the project. I'm not closing this bug report just yet as I'd like to first better understand what the current setup is lacking for you. Cheers!
Bug#965360: apparmor-profiles: Please meke seperate packages for each apparmor profile
Package: apparmor-profiles Version: 2.13.4-3 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Maintainer, currently when the apparmor-profiles package is installed, it installs several apparmor profile files. In this way users can have all or none of the profiles installed in their systems. Sometimes a user wants only a specific profile (or profiles) installed and doesn't really want the other profiles to be installed as well because: - he doesn't need the other profiles, - he has his own alternative profiles, which differ in rule sets, - the other profiles simply cause some issues with applications they confine. What do you think about another approach, which is to create separate packages containing individual apparmor profiles? For instance, there's the usr.sbin.dnsmasq file which is related to the dnsmasq package. In this case there could be a package named dnsmasq-apparmor-profile which would include the usr.sbin.dnsmasq file. If a user wanted to install dnsmasq and also wanted it to be confined by the default apparmor profile provided by Debian, he could also install dnsmasq-apparmor-profile, which wouldn't affect any other app functionality. Also, there are many profiles under /usr/share/apparmor/extra-profiles/ which aren't enabled, and probably no one uses them at all. If there was a package, for instance, postfix-apparmor-profile containing all the usr.lib.postfix* files installed under /etc/apparmor.d/ , I think more people would test the profiles, which would contribute to better development of the profiles themselves. Probably not all of the files included currently in the apparmor-profiles package can be separated in the way described above, but there are cases where this can be done, and I think it should be done. Tell me what do you think about this solution. -BEGIN PGP SIGNATURE- iHUEARYKAB0WIQR1ZhNYxftXAnkWpwEy2ctjR5bMoQUCXxVrFAAKCRAy2ctjR5bM oUuSAP9vC0YwQpOCkhvml75GWrKVeWRNtxsLcDmG0G4qi/DhpQEA6Sqw0tiaYwve 1rgG46iE976oC6uVliwRSba/rkBEkAs= =5jJs -END PGP SIGNATURE-
