Project

General

Profile

Feature #11826

Evaluate using Whonix' control-port-filter-python as Tor control port filter

Added by adrelanos about 3 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
09/22/2016
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:


Related issues

Related to Tails - Feature #11542: Evaluate using roflcoptor as Tor control port filter Resolved 06/23/2016
Related to Tails - Feature #7870: Include OnionShare Resolved 12/07/2016
Related to Tails - Feature #9001: Onion Circuits should connect via the Tor control port filter Resolved 03/03/2015
Related to Tails - Feature #8173: Make Ricochet usable in Tails Rejected 10/25/2014
Blocks Tails - Feature #6742: Make tor-controlport-filter reusable Resolved 02/21/2014

History

#1 Updated by adrelanos about 3 years ago

Somehow I cannot edit the original ticket. Never mind. Adding it as comment.

cpfpy wildcard support for some time now and recently event support was merged. So soon we can use onionshare etc. in Whonix. I would wonder why it should not be reuseable in Tails with very few modifications.

#2 Updated by intrigeri about 3 years ago

  • Related to Feature #11542: Evaluate using roflcoptor as Tor control port filter added

#3 Updated by intrigeri about 3 years ago

#4 Updated by intrigeri about 3 years ago

  • Blocks Feature #6742: Make tor-controlport-filter reusable added

#5 Updated by intrigeri about 3 years ago

  • Related to Feature #9001: Onion Circuits should connect via the Tor control port filter added

#6 Updated by intrigeri about 3 years ago

#7 Updated by intrigeri about 3 years ago

  • Subject changed from Evaluate using control-port-filter-python as Tor control port filter to Evaluate using Whonix' control-port-filter-python as Tor control port filter
  • Status changed from New to Confirmed

#8 Updated by intrigeri about 3 years ago

FWIW, last time this was suggested on tails-dev@, my initial code review was unconvincing (e.g. hand-made logging and service management while we have systemd nowadays, and quite a few troubling programming style issues). I don't remember the details though, and chances are that the code has changed a lot since then, so we should definitely evaluate this option. Thanks for pointing us to it again :)

#9 Updated by adrelanos about 3 years ago

I'd be surprised if Tails would go for roflcopter. (details: #11542#note-8) So I guess your options boil down to using cpfpy or reinvent cpfpy functionality in Tails tor-controlport-filter. And it would be a shame if cpfpy did not work for you. I'd very much like to have a shared code base for that one. I would wonder if more than a few simple patches would be required.

Yes, a lot has changed in cpfpy since then.

Do you have any examples, a (ideally minimal) python daemon that uses modern logging and service management? While I am at working on cpfpy, I guess it would be a rather small effort to port to that method.

#10 Updated by intrigeri about 3 years ago

And it would be a shame if cpfpy did not work for you. I'd very much like to have a shared code base for that one.

Agreed!

Do you have any examples, a (ideally minimal) python daemon that uses modern logging and service management?

I have no handy examples, but logging to stdout, and not forking / detaching from the terminal + a basic systemd unit file, should be enough nowadays. Ideally add support for the systemd notification protocol, which requires about 3 lines of code. If the custom logging + service management code is still in cpfpy, then this should allow you to drop quite some custom code and get a more maintainable codebase as a result :)

#11 Updated by adrelanos about 3 years ago

cpfpy is now logging to stdout, hence ending up in journal. No longer forking. Systemd unit file functional.

I would like to add systemd notification protocol, but the python libs for doing so are not available in jessie yet.

- https://packages.debian.org/jessie-backports/python-systemd
- https://packages.debian.org/unstable/main/python-sdnotify

I could make a call to the /bin/systemd-notify. That would work for the --ready notification but I am not sure it is a good idea to call --status every few seconds for daemon-still-alive notification.

Therefore systemd notification protocol has been assigned for the Debian stretch work milestone. Input, examples welcome, perhaps I can implement this already.

#12 Updated by intrigeri about 3 years ago

cpfpy is now logging to stdout, hence ending up in journal. No longer forking. Systemd unit file functional.

Yeah! \o/

I would like to add systemd notification protocol, but the python libs for doing so are not available in jessie yet.

I think you're probably a bit confused. We do use python3-systemd successfully on Jessie:

#13 Updated by adrelanos about 3 years ago

That's great. However, will take a while. We yet have to port to python3. Help welcome. :)

#14 Updated by anonym about 3 years ago

  • Status changed from Confirmed to Resolved

In the end it seems Whonix might use our improved filter (for #7870) instead: https://mailman.boum.org/pipermail/tails-dev/2016-November/011031.html

Also available in: Atom PDF