Szerző: anonym Dátum: Címzett: The Tails public development discussion list Tárgy: Re: [Tails-dev] [Whonix-devel] Tails control port filter proxy in
Whonix?
Patrick Schleizer: > Hi!
>
> [override] will probably work for Whonix. Joy and me drafted a plan.
>
> In one sentence: We at Whonix invent a new a separate config folder,
> parse it with a yml merger python script, and generate another yml file
> that gets passed to tor-controlport-filter by Tails.
Ok. My understanding of this proposal is that you no longer need any sort of "filter rules merging" in tor-controlport-filter itself, correct? If so, great! :) Feel free to send a PR with your other changes applied to tor-controlport-filter in Tails Git! Otherwise I'll do it myself later this week.
> In more detail:
>
> - We'll at Whonix invent /usr/lib/tor-controlport-filter-merger.
> - And ship that as opt-in or in a separate package by Whonix.
> - (If opt-in, we enable it in a separate Whonix package.)
>
> - /etc/tor-controlport-filter.d
> -- We tell Whonix users to ignore it.
> -- Internally used by /usr/lib/tor-controlport-filter .
> -- Will contain
> --- tails-default-profies.yml (for the sake of sharing the package
But they are not useful in Whonix since they only work for loopback connections (i.e. only for applications running on the gateway, which should be nothing except for tor, essentially). Right?
> and perhaps we also benefit from a profile for arm/nyx)
For the record, we'll remove Nyx/arm in Tails 2.10, due tomorrow. :)
> --- 30_autogenerated.yml
>
> - /etc/tor-controlport-filter-merger.d
> -- Will be used by Whonix and its users
> -- 30_whonix_default.yml - will by shipped by Whonix by default
> -- 40_onionshare.yml - user defined
> -- 40_ricochet.yml - another user defined etc.
>
> - /usr/lib/tor-controlport-filter-merger parses both,
> -- /etc/tor-controlport-filter-merger.d and
> -- /usr/local/etc/tor-controlport-filter-merger.d (for Qubes-Whonix)
> -- and creates /etc/tor-controlport-filter.d/30_autogenerated.yml
>
> - Our tor-controlport-filter.service systemd service will in essence
> look like this.
> -- ExecStartPre=/usr/lib/tor-controlport-filter-merger
> -- ExecStart=/usr/lib/tor-controlport-filter
>
> Does that sound like that could work out?
