Hi! intrigeri: > Patrick Schleizer wrote (09 Mar 2015 01:47:23 GMT) : >> I would like to inform you about the existence of >> control-port-filter-python, a fork of tor-controlport-filter by >> Tails. > > Thanks!
Glad you like it! >> * Configurable by dropping .d-style configuration snippets into >> /etc/cpfpy.d. I.e. whitelist can be extended by dropping snippets. > > Looks useful too, for easier code sharing between distros! Yes, that is part of the idea. Another idea is to allow other, optional packages dropping a configuration snippets. For example, if there was a "hidden-services-configurator" or so package, it could just drop a snippet as required. (Similar to /etc/rsyslog.d, where everyone drops what one needs without getting into each others way.) >> * Support to answer 'getinfo net/listeners/socks' with the lie >> '250-net/listeners/socks="127.0.0.1:9150"'. > > The idea is to reply to Torbutton whatever it wants to hear when it > builds about:tor and its green onion icon, right ? Partly, yes. [The other minor one in small font is this "We're keeping it, because it is not necessary for Tor Button get a full list of all ports Tor is listening on. If an attacker compromised Whonix-Workstation, hiding that list has an advantage. The attacker can probe what ports are available to that Whonix-Workstation, but if the user added extra ports not available to the compromised Whonix-Workstation (only available to another Whonix-Workstation listening on another IP), at least those remain secret. (This is a bit theoretical, because a compromised Whonix-Workstation can spoof it's LAN IP and most likely very few users are using ARP spoofing defenses. Should we add ARP spoofing defenses by default at some point, we at least don't have to worry about this point.)"] >> * Honors signals sigterm, sigint. > > Do you mean that Tails' current version ignores such signals? I didn't explicitly test this inside Tails, but I would wonder if Tails' current version supports those. Because this was one of the original limitations, we imported, I think. >> * Complete sysvinit script. > > The great news is that the boilerplate that makes that script 159 > lines long will soon be unnecessary, and be replaced by something a > little bit nicer (to my eye at least), such as: > > https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/lib/systemd/system/tor-controlport-filter.service?h=feature/jessie > > :) Thanks. Systemd support is planned (for whole Whonix). I think forking that file makes sense as well. Are maintainers expected, Debian policy, convention or otherwise to remove sysvinit scripts from packages once they have a systemd unit and are ready to jessie? Or to keep those? I don't mind either way. > * The amount of global variables usage is troubling. * Some exception > catching feels a bit too wide. * The list of "if line.startswith" > that follows "for line in c" wants to be replaced by a dispatch table > or something more readable. troubadour might work on these. See: https://phabricator.whonix.org/T243 >> * Supports logging. > > It feels strange to me to add direct log files handling (as opposed > to using the syslog interface or the native systemd journal's one) > to a system-wide daemon in 2015: that's one more log file that won't > be aggregated in the systemd journal, so one has to look in one more > place when trying to debug something. Anyway, that's probably a > matter of taste :) > > The good news is that the logging module supports syslog, so it > seems easy enough to adjust according to one's taste. Perhaps that > could be supported with a command-line option? (I guess the answer > will be "patches welcome" -- fair enough :) The answer is not yet "patches welcome". troubadour's comment was: > About logging, would it be an advantage to use syslog or systemd journal instead of a dedicated log file? For debugging, it seems better to keep it separate. I don't have a strong opinion either way. Well, having a "just show me only control-port-filter-python log entries" command seems important, but that will most likely be possible either way? Having a separate file also seems simple and useful or is that not hip anymore nowadays? Not required, once is accustomed to enter the required systemd command to show only the log one wants to see? What [python] lib / function / way would be a standard, policy, and whatnot conform, good one for logging? What's the usual way to do that nowadays? Cheers, Patrick _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
