Re: [Tails-dev] Tails control port filter proxy in Whonix?

Delete this message

Reply to this message
Author: anonym
Date:  
To: The Tails public development discussion list, Whonix-devel
Subject: Re: [Tails-dev] Tails control port filter proxy in Whonix?
Patrick Schleizer:
> Whonix has forked tor-controlport-filter by Tails.
>
> https://github.com/Whonix/control-port-filter-python
>
> Whonix is using a different configuration parser.


Yay! Let's try to make this fork short-lived! Note that Tails' version has changed quite a lot since you forked -- please try to keep your fork delta minimal (i.e. only do what *must* be done)!

> This is now documented in details here:
>
> https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy/tor-controlport-filter/config


So, since all your filters match *everything*, you could actually merge all the filters yourself into a single filter rule file, right? In fact, the only non-sytlistic reason you want merging of multiple matched rules is to allow Whonix users to add their own filters without overwriting yours (which causes issues during Whonix upgrades), correct?

If so, I think I have a simpler solution: we introduce a new top-level key called `override` which takes a list of strings. If such a filter is matched together with a filter whose name is listed in `override`, then the `override`-filter is merged into the other one, and has priority whenever there's any ambiguity. So with this, Whonix would ship a single, nicely commented filter called 'whonix', and users that need to modify it simply creates a filter with `override: ['whonix']`.

The only drawback I can see is that Whonix cannot organize the filters in separate files this way, but I think that is a small prize to pay for such a simple solution to this problem (which I fear otherwise can make it really hard to reason about filters when they grow in number). I actually think Whonix having a single file is slightly advantageous since you use the same match rules in every filter.

Would this work for you?

Beyond that, I'll add your `--listen-interface` option, and I'll add a `--filters-dir` option that can be used to override the default filters dir, and that can be passed multiple times (so you'll pass `--filters-dir /etc/tor-controlport-filter.d --filters-dir /usr/local/etc/tor-controlport-filter.d/`).

Would this be enough to kill your fork?

Cheers!