Package: tor Version: 0.2.6.10-1 Severity: wishlist Owner: intrig...@debian.org X-Debbugs-Cc: lu...@debian.org
Hi, a common source of problems with little-t-tor's AppArmor confinement has been the hard-coded list of pluggable transports in /etc/apparmor.d/abstractions/tor: whenever someone creates a new PT implementation and people start using it, the tor service fails to start on AppArmor-enabled systems until 1. we add that new PT to the "tor" AppArmor abstraction; and 2. end-users upgrade their tor package to a version that contains the update. I remember seeing too many bug reports filed on the Tor bug tracker (mostly by Ubuntu users) about it: they install whatever PT is currently best for their use case from deb.torproject.org, but they still have a tor package from some stable Debian or derivative distro that hasn't seen the (1) update yet. Fixing this would improve UX and lower our maintenance workload. To fix this, I propose that we: a) add "#include tor.d" to abstractions/tor b) move each already present PT-related rules from abstractions/tor to abstractions/tor.d/<PT>, that would be shipped in the corresponding PT package. I'm willing to implement this (with low/moderate priority) and submit patches to the tor, obfsproxy and obfs4proxy packages. Sounds good? Any foreseeable issue with it? Better ideas? Cheers, -- intrigeri
