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!

_______________________________________________
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Reply via email to