Hallo, * intrigeri [Wed, Jun 02 2021, 10:13:12AM]: > Control: tag -1 + upstream > Control: forwarded -1 > https://gitlab.com/apparmor/apparmor-profiles/-/merge_requests/51 > Control: tag -1 + moreinfo > > Hi, > > Eduard Bloch (2021-05-28): > > see attachment, your config which doesn't allow link calls, which > > sporadically breaks operation of apt-cacher-ng in unexpected ways. > > Thanks! I've turned this patch into an upstream merge request. > > I see you've made this bug RC. I'd like to better understand the
I set it RC because it deliberately breaks other package's (legal) operations, and installing such booby traps was not properly announced. And because you take away the control over the package's behavior from the maintainers and push them to "collaboration", if I understood https://wiki.debian.org/AppArmor/Contribute/MergeProfileFromUpstream correctly. In a way I don't like (shoot first, ask later). > severity, so I can figure out what I should do for Bullseye. > I'm wondering because I'm using this AppArmor policy on sid with There were issues with rare file truncation, one of the potential improvements was applies after soft-freeze. Line 847 at https://salsa.debian.org/blade/apt-cacher-ng/-/blob/upstream/sid/source/fileitem.cc which is a more careful rotation of files with volatile contents. > apt-cacher-ng myself, and I can't find traces of such denials in > my logs. Please. Just because you don't see issues does not mean that issues don't exist. > Could you please help me understand what kind of apt-cacher-ng > operations (or configuration) trigger these denials and are broken by > the current AppArmor policy? When the mentioned mechanism was put in place, regular operation started breaking. This also affects the expiration jobs, therefore your cache will keep growing when users use non-stable distros. Or what exactly did make you think that "rw" is okay and everything else can be dumped? Where are we? "I see all cars on my road are driving straight, means that we can remove all steering wheels"? *facepalm* Eduard.