Patrick Schleizer:
> anonym:
>> Yay! Let's try to make this fork short-lived!
>
> Yes! :)
>
>> 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)!
>
> Our diff of the filter is quite mergable, I guess. In summary:
>
> - filters = yaml.safe_load(fh.read())
> - #!/usr/bin/python3 -u so python exceptions end up in journal
> - config parser
> - --listen-interface (which you already said you want to add)
>
> (And the packaging stuff is not all that difficult?)
>
> We have a ticket for merging Tails' version into Whonix's version so we
> get your enhancement and so the diff looks simpler. [1]
Let me know when that has happened!
>> 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?
>
> No. (However, I am not sure I fully understood your proposal.
> Technically at the moment all config file snippets are merged into the
> same merged filter rule.)
Yes, currently the multiple filters you use are merged into a single large filter. Hence, you might as well ship that merged filter (in a single file) instead of these multiple ones.
> Having the filters split in multiple files is very much desirable.
For now I'll ignore "desirability" due to organizational improvement -- let's only talk about the results.
> We
> want to ship a maximally restrictive config by default. And then allow
> users to make it more permissive as required depending on their use case.
Ack. So your default "maximally restrictive config" would be the single filter named 'whonix'. And users can create a filter with `override: ['whonis']` and their additional rules.
> Just two different configs, one for maximum restrictive vs one for
> custom maximum permissive is probably not right balance here.
What balance is lost here?
> Having to use something like "override: ['whonix']" and somehow have a
> hierarchy of files named that way, if they are splittable/stackable,
> would of course not be an issue.
A single `override` filter can achieve the same as multiple `override` filters -- just manually merge them, and then you have that "single" `override` filter.
So, in the end, it seems that nothing in terms of expressibility is lost by not having general merging, but just the `override` functionality. Am I wrong, or is there still something unclear about this?
>> 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/`).
>
> That's great! (Please don't fail if the folder does not exist - logging
> that only would be a lot better.)
Noted!
Cheers!
