TLDR:
Does Tor's control protocol actually support something like ; ? I.e. something like signal newnym ; getinfo address ? How many of there separators are there? Can you provide examples please?
Background:
At the moment we are implementing support for whitelisting wildcards for control-port-filter-proxy-python [0] to support Onionshare and Ricochet. [1] [2] [3] [4]
Does Tor's control protocol actually support something like ; ? If it does, then this would complicate the wildcard feature.
If we whitelisted the wildcard add_onion *, we don't want it to match some hypothetical feature add_onion * ; .... I.e. not add_onion * ; GETINFO address.
(If it was the case, then we would have to limit the wildcard (*) from example SETCONF HiddenServicePort * to exactly one [numeric] argument etc. Or better, correctly parse multi lined commands. Or as stopgap, reject these separators since no applications using Tor's control protocol are currently using those.)
Cheers, Patrick
[0] https://github.com/Whonix/control-port-filter-python https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy [1] https://phabricator.whonix.org/T446 [2] https://phabricator.whonix.org/T445 [3] https://www.whonix.org/wiki/Next#onionshare [4] https://phabricator.whonix.org/T448
(Asked Roger by mail, said it's okay to post this on tor-dev.)
Hi Patrick,
No, the protocol does not support this. The only command separator is a newline. Implementing this would likely be hard anyway, as the output of the double command would be hard to parse.
Tom
Op 10/01/16 om 18:02 schreef Patrick Schleizer:
TLDR:
Does Tor's control protocol actually support something like ; ? I.e. something like signal newnym ; getinfo address ? How many of there separators are there? Can you provide examples please?
Background:
At the moment we are implementing support for whitelisting wildcards for control-port-filter-proxy-python [0] to support Onionshare and Ricochet. [1] [2] [3] [4]
Does Tor's control protocol actually support something like ; ? If it does, then this would complicate the wildcard feature.
If we whitelisted the wildcard add_onion *, we don't want it to match some hypothetical feature add_onion * ; .... I.e. not add_onion * ; GETINFO address.
(If it was the case, then we would have to limit the wildcard (*) from example SETCONF HiddenServicePort * to exactly one [numeric] argument etc. Or better, correctly parse multi lined commands. Or as stopgap, reject these separators since no applications using Tor's control protocol are currently using those.)
Cheers, Patrick
[0] https://github.com/Whonix/control-port-filter-python https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy [1] https://phabricator.whonix.org/T446 [2] https://phabricator.whonix.org/T445 [3] https://www.whonix.org/wiki/Next#onionshare [4] https://phabricator.whonix.org/T448
(Asked Roger by mail, said it's okay to post this on tor-dev.) _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Parsing and escaping things on one line is often a pain.
Atomic batching might be useful, though I've no use case.
< BATCH BEG label < cmd1 < cmdN < BATCH END label < BATCH PRINT / DELETE label < BATCH EXEC label [instance]
BATCH RESULT label [instance]
< BATCH RESULT AUTODEL params [label] [if RESULTs are buffers instead of immediate pipes]
Patrick Schleizer patrick-mailinglists@whonix.org writes:
Does Tor's control protocol actually support something like ; ?
I'm not sure if this helps for your use-case, but my "carml" command-line tool can read commands from a pipe and execute them all. A simple example:
echo "GETINFO process/user" > foo echo "GETINFO process/pid" >> foo cat foo | carml cmd -
So, this will produce stdout like this:
process/user=debian-tor process/pid=1234
(Of course, you can make the above shorter/different in various ways, and GETINFO accepts multiple keys already, but "illstrative purposes" etc...)
-
grarpamp -
meejah -
Patrick Schleizer -
Tom van der Woerdt