> Patrick Schleizer:
>> Hi,
>> as discussed elsewhere, yes, it would be great if we could share code bases!

I got excited about doing some coding, so now we're closer to being able
to do this! Still, don't feel bad if you in the end decide *not* to use
our filter. :)

>> - Honors signals sigterm, sigint, keyboard interrupt.
> I guess?

Now it definitely does.

> In conclusion, I think the truth is that Whonix switching to our filter
> will require some work to reach feature-parity with you current filter,
> and you will not really gain anything by doing so except code sharing.
> YMMV. That said, I'd happily implement match-hosts and the two
> additional types of rules I mentioned above if that would be enough for you.

I actually went ahead and implemented these, and I've successfully been
able to run a client on a different host than the filter, like in
Whonix. This is how I imagine the onionshare filter configuration Whonix
needs would look like:

    - match-hosts:
        - ''
          - 'version'
          - 'onions/current'
          - pattern:  'net/listeners/socks'
            response: '250-net/listeners/socks=""'
          - '__owningcontrollerprocess'
          - pattern:     'NEW:BEST Port=80,(176\d\d)'
            replacement: 'NEW:BEST Port=80,{}'
          - '.+'
          suppress: true
          suppress: true

If you need help deciphering the above I refer you to the "docs":

Thoughts about the configuration format are highly welcome (but I doubt
I'd like to move away from YAML)!

It would be interesting to see if this works for you in Whonix. You
definitely will have to look at the --listen-address option ( or
the address the gateway connects to), and maybe the
--control-cookie-path and --control-socket-path options (yes, the filter
requires a cookie protected Tor ControlSoket for now -- patches welcome
for other modes!).

> Still, I feel we've left out roflcoptor from this discussion. At the
> moment the biggest turn-off for me is that it is written in Go, a
> language I have little interest in learning, and the lack of Debian
> packaging. I'm not sure what else to say, but it just feels like there
> needs to be a discussion before we'd proceed in collaborating on a
> control port filter.

I've now seen that you raised similar concerns a bit earlier in the
thread, so perhaps that is good enough for dismissing roflcoptor (at
least for now) without feeling too bad due to NIH syndrome.

I don't know if/how we should proceed, but here's what I think of the
remaining (according to an earlier email in the thread) tickets you have
for this in Whonix vs. our filter:

> -

Orthogonal to the filter, so skipped.

> -


> -

I'd need more details of what the idea is here.

Any way, it seems that if one is careful when writing the rules for
ADD_ONION, one can limit the number simply by making sure there's that
number of possible matches of [host:]ports. E.g. the above filter for
onionshare can at most allow 100 ports. Solved?

> -

I'd need more details of what the idea is here.

> -

Like I said, this should be easy. Patches welcome! :)


Let me end with: if you test our filter in Whonix, and decide it's the
way to go, then I'll try to do the Debian packaging unless someone wants
to contribute it!


Tails-dev mailing list
To unsubscribe from this list, send an empty email to

Reply via email to