Yes, these were not merged. Somehow slipped through. Now all merged. Should work now?
[code]
W: control-port-filter-python: systemd-service-file-refers-to-obsolete-target lib/systemd/system/control-port-filter-python.service syslog.target
N:
N: The systemd service file refers to an obsolete target.
N:
N: Some targets are obsolete by now, e.g. syslog.target or dbus.target. For
N: example, declaring After=syslog.target is unnecessary by now because
N: syslog is socket-activated and will therefore be started when needed.
N:
N: Severity: normal, Certainty: certain
N:
N: Check: systemd, Type: binary
N:[/code]
W: control-port-filter-python: systemd-service-file-refers-to-obsolete-target lib/systemd/system/control-port-filter-python.service syslog.target
N:
N: The systemd service file refers to an obsolete target.
N:
N: Some targets are obsolete by now, e.g. syslog.target or dbus.target. For
N: example, declaring After=syslog.target is unnecessary by now because
N: syslog is socket-activated and will therefore be started when needed.
N:
N: Severity: normal, Certainty: certain
N:
N: Check: systemd, Type: binary
N:
systemd unit: removed ‘syslog.target’ from ‘After=’ to fix lintian warning ‘W: control-port-filter-python: systemd-service-file-refers-to-obsolete-target lib/systemd/system/control-port-filter-python.service syslog.target’ - Whonix Forum
https://github.com/Whonix/control-port-filter-python/commit/7c393884622c719bd482dd7cf8447b067a7003c8
StandardOutput=syslog
StandardError=syslog
Wondering, do we have any reason for using that?
Pushed your commits to troubadoour.
Wondering, do we have any reason for using that?No special reason, it was taken from a generic unit file. It does not seem to write anything to syslog.
systemd unit: removed ‘StandardOutput=syslog’ and ‘StandardError=syslog’ as per Whonix Forum
https://github.com/Whonix/control-port-filter-python/commit/838061e72547b308adee51182350135c830fc2c5
Merged.
Removed argument parsing (start / stop / restart) in cpfpd, as it’s managed by systemd.
remove argument parsing, done in daemon/systemd · troubadoour/control-port-filter-python@3c1f475 · GitHub
Merged.
workaround for ‘dh_installinit should run systemd-tmpfiles if a /usr/lib/tmpfiles.d/ snippet gets shipped for systemd-only packages also’ - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795519
https://github.com/Whonix/control-port-filter-python/commit/20390f32e6d9a9271580500caa57a69f66df94a8
(Similar to this change: Whonix Forum)
Merged.
Tested. Works fine. Merged. And closed the ticket.
( ⚓ T445 CONTROL_PORT_FILTER_WHITELIST wildcard feature )
Added some minor commits on top. Please review and merge.
Added the following to the config.
CONTROL_PORT_FILTER_ALLOW_WILDCARDS=true
CONTROL_PORT_FILTER_WHITELIST=protocolinfo 1
CONTROL_PORT_FILTER_WHITELIST=authchallenge *
Then run the following on a Qubes-Whonix-Gateway.
tor-prompt -i 10.137.3.1:9052
Did not work.
Unable to authenticate: All lines should end with CRLF
Could this be a more general error? Should we end lines with CRLF?
(What I really was doing was trying multi lined commands in context of research control port filter proxy whiltelist wildcard security implications.)
End lines with CRLF now.
https://github.com/Whonix/control-port-filter-python/commit/7fe75ffab2a5a6ce0716abbe6c496ca15dbc6cda
Since GitHub - Whonix/anon-ws-disable-stacked-tor functionality interacts with https://github.com/Whonix/control-port-filter-python, I am also discussing anon-ws-disable-stacked-tor here.
( Dev/anon-ws-disable-stacked-tor - Whonix also needs an update. )
Also help wanted with Control Port Filter Proxy Python (cpfpy)! See:
The default anon-ws-disable-stacked-tor config file should explain most of what anon-ws-disable-stacked-tor does.
Now it is almost possible for python-stem based applications to do Tor Control Auth Cookie authentication. One small piece for this is still missing.
We would have to whitelist protocolinfo 1 by default also. It would answer (and relay back to the workstation):
250-PROTOCOLINFO 1
250-AUTH METHODS=COOKIE,SAFECOOKIE COOKIEFILE="/var/run/tor/control.authcookie"
250-VERSION Tor="0.2.8.7"
250 OK
Does that look alright? Should we whitelist protoclinfo? Or does anything speak against this? If so, we could implement a hardcoded, fake answer, another “lie”.
Using https://github.com/subgraph/roflcoptor/blob/master/session.go as a reference - its ok to whitelist protocolinfo however their filter lies about the supported authentication types.
1 Like