Feature #11542
Evaluate using roflcoptor as Tor control port filter
0%
Description
https://github.com/subgraph/roflcoptor
It seems to be used by Subgraph and the successor of or-ctl-sieve, which I mentioned in Feature #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.
Subtasks
Related issues
Related to Tails - |
Resolved | 2015-03-03 | |
Related to Tails - |
Resolved | 2016-12-07 | |
Related to Tails - |
Resolved | 2014-05-27 | |
Related to Tails - |
Resolved | 2013-10-21 | |
Related to Tails - |
Resolved | 2016-09-22 | |
Blocks Tails - |
Resolved | 2014-02-21 |
History
#1 Updated by sajolida 2016-06-23 03:39:43
- Description updated
#2 Updated by sajolida 2016-06-23 03:39:54
- blocks
Feature #6742: Make tor-controlport-filter reusable added
#3 Updated by sajolida 2016-06-23 03:40:27
- related to
Feature #9001: Onion Circuits should connect via the Tor control port filter added
#4 Updated by sajolida 2016-06-23 03:40:36
- related to
Feature #7870: Include OnionShare added
#5 Updated by sajolida 2016-06-23 03:40:41
- related to
Feature #6788: Use stem in the filtering proxy for the Tor control port added
#6 Updated by sajolida 2016-06-23 03:40:54
- related to
Feature #6384: Filtering proxy for the Tor control port added
#7 Updated by sajolida 2016-06-23 03:46:40
- Subject changed from Evaluate using roflcoptor as control port filter to Evaluate using roflcoptor as Tor control port filter
Started a public discussion there: https://secure-os.org/pipermail/desktops/2016-June/000126.html.
#8 Updated by adrelanos 2016-09-22 17:50:51
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. -> Feature #11826
#9 Updated by intrigeri 2016-09-23 03:08:36
- related to
Feature #11826: Evaluate using Whonix' control-port-filter-python as Tor control port filter added
#10 Updated by anonym 2016-11-12 13:26:09
- 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. -> Feature #11826
… and we’ll go with our improved filter (implemented for Feature #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).