Project

General

Profile

Feature #11542

Evaluate using roflcoptor as Tor control port filter

Added by sajolida over 3 years ago. Updated almost 3 years ago.

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

0%

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

Description

https://github.com/subgraph/roflcoptor

It seems to be used by Subgraph and the successor of or-ctl-sieve, which I mentioned in #6742#note-14.

If it matches our requirements and is likely to be maintained, maybe we should replace our custom control port filter with this.


Related issues

Related to Tails - Feature #9001: Onion Circuits should connect via the Tor control port filter Resolved 03/03/2015
Related to Tails - Feature #7870: Include OnionShare Resolved 12/07/2016
Related to Tails - Feature #6788: Use stem in the filtering proxy for the Tor control port Resolved 05/27/2014
Related to Tails - Feature #6384: Filtering proxy for the Tor control port Resolved 10/21/2013
Related to Tails - Feature #11826: Evaluate using Whonix' control-port-filter-python as Tor control port filter Resolved 09/22/2016
Blocks Tails - Feature #6742: Make tor-controlport-filter reusable Resolved 02/21/2014

History

#1 Updated by sajolida over 3 years ago

  • Description updated (diff)

#2 Updated by sajolida over 3 years ago

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

#3 Updated by sajolida over 3 years ago

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

#4 Updated by sajolida over 3 years ago

#5 Updated by sajolida over 3 years ago

  • Related to Feature #6788: Use stem in the filtering proxy for the Tor control port added

#6 Updated by sajolida over 3 years ago

  • Related to Feature #6384: Filtering proxy for the Tor control port added

#7 Updated by sajolida over 3 years ago

  • Subject changed from Evaluate using roflcoptor as control port filter to Evaluate using roflcoptor as Tor control port filter

#8 Updated by adrelanos about 3 years ago

I considered roflcopter for Whonix.

- written in golang, "because all subgraph tools are written in golang" which is not a great reason, therefore requires compilation which makes packaging harder
- has quite a few golang library dependencies, which are not packaged for Debian either
-- verified download of those and/or source code verification adds up
- depending on subgraph procsnitch - https://github.com/subgraph/roflcoptor/issues/56
-- therefore more complexity and more dependencies

Therefore I rather improved control-port-filter-python. It has wildcard support for some time now and recently event support was merged. So soon we can use onionshare etc. in Whonix. -> #11826

#9 Updated by intrigeri about 3 years ago

  • Related to Feature #11826: Evaluate using Whonix' control-port-filter-python as Tor control port filter added

#10 Updated by anonym almost 3 years ago

  • Status changed from Confirmed to Resolved

adrelanos wrote:

I considered roflcopter for Whonix.

- written in golang, "because all subgraph tools are written in golang" which is not a great reason, therefore requires compilation which makes packaging harder
- has quite a few golang library dependencies, which are not packaged for Debian either
-- verified download of those and/or source code verification adds up
- depending on subgraph procsnitch - https://github.com/subgraph/roflcoptor/issues/56
-- therefore more complexity and more dependencies

I agree with these concerns.

Therefore I rather improved control-port-filter-python. It has wildcard support for some time now and recently event support was merged. So soon we can use onionshare etc. in Whonix. -> #11826

... and we'll go with our improved filter (implemented for #7870) which uses regexes. It seems Whonix will too: https://mailman.boum.org/pipermail/tails-dev/2016-November/011031.html

So, in conclusion, let's not use roflcoptor now, but let's reevaluate if/when it's packaged in Debian. OTOH, I sort of like the Python ecosystem around Tor (much thanks to stem) and worry that a separate ecosystem inGolang isn't worth it (e.g. in the end it will re-implement much of stem and so on).

Also available in: Atom PDF