anonym:
> 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:
- '10.1.1.42'
commands:
GETINFO:
- 'version'
- 'onions/current'
- pattern: 'net/listeners/socks'
response: '250-net/listeners/socks="127.0.0.1:9150"'
GETCONF:
- '__owningcontrollerprocess'
ADD_ONION:
- pattern: 'NEW:BEST Port=80,(176\d\d)'
replacement: 'NEW:BEST Port=80,10.137.6.41:{}'
DEL_ONION:
- '.+'
events:
SIGNAL:
suppress: true
CONF_CHANGED:
suppress: true
HS_DESC:
If you need help deciphering the above I refer you to the "docs":
http://git.tails.boum.org/tails/tree/config/chroot_local-includes/usr/local/lib/tor-controlport-filter?h=feature/7870-include_onionshare
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 (0.0.0.0 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:
> - https://phabricator.whonix.org/T561
Orthogonal to the filter, so skipped.
> - https://phabricator.whonix.org/T562
Solved!
> - https://phabricator.whonix.org/T564
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?
> - https://phabricator.whonix.org/T565
I'd need more details of what the idea is here.
> - https://phabricator.whonix.org/T566
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!
Cheers!
