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
