onioncircuits: add TOR_CONTROL_* environment variables
We'd like onioncircuits to play nice with the Subgraph tor control port filtering daemon:
To do this we need onioncircuits to connect to a specified unix domain socket in which
our filtering daemon is listening. Here's the simple four line patch:
#1 Updated by intrigeri almost 4 years ago
- Status changed from New to In Progress
- Assignee set to anonym
- Target version set to Tails_2.4
- QA Check set to Ready for QA
- Type of work changed from Debian to Code
- Affected tool set to Onion Circuits
We'd like onioncircuits to play nice with the Subgraph tor control port filtering daemon: https://github.com/subgraph/roflcoptor
To do this we need onioncircuits to connect to a specified unix domain socket in which our filtering daemon is listening. Here's the simple four line patch:
Thank you. anonym, can you please code-review this?
(Once all pending Onion Circuit patches are out, I can make an upstream release, and then if time allows it can flow into Tails 2.4 via sid→testing→jessie-backports, even if I don't manage to do #11361. I'll upload a backport of 0.3-1 so it clears the backports NEW queue, and then next time it'll be accepted automatically.)
#2 Updated by anonym almost 4 years ago
- Assignee changed from anonym to dawuud
- % Done changed from 0 to 30
- QA Check changed from Ready for QA to Info Needed
- Feature Branch set to onioncircuits:feature/11402-control-env-vars
Thanks for your contribution!
I have a few issues with this patch:
TOR_CONTROL_PORTis a poor name since it in fact is used for the path to the socket control file, given that we pass it to
TOR_CONTROL_SOCKETis commonly used in the environment for that purpose and is IMHO a better name.
- As a general rule I think it is good to avoid overriding library defaults, and how you handle the
pathkeyword argument violates that. I.e. when the env var is not set, we should do what
onioncircuitsdo without your patch (calling
While looking at this I also noticed that
connect_socket_file() is deprecated in favor of
connect(), which has the added benefit that we also easily can support using a control port. So instead of forcing such code ~maintenance work on you I have pushed a branch called
feature/11402-control-env-vars -- please let us know (on this ticket) if it suites your needs (and please reassign the ticket to me then)!
#5 Updated by anonym almost 4 years ago
- Subject changed from onioncircuits: add TOR_CONTROL_PORT environment variable to onioncircuits: add TOR_CONTROL_* environment variables
- Assignee changed from anonym to alant
- % Done changed from 30 to 50
- QA Check changed from Info Needed to Ready for QA
Let's make this happen, then! alant, what do you think?