anonym: > Patrick Schleizer: >> [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! :)
I guess so, right. Unless any of the Tails profiles use '*'? But in that case we might be able to just config-package-dev displace the profile. > 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. Let's see who is faster. Can't say yet. >> 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? Right. [And a rather minor point...: tor-arm [now nyx] is one that could use a profile. Users tend to create screenshots of arm, so redacting any IP addresses would be nice. Also terminal emulators such as konsole might have bugs. By limiting what what tor-arm gets to see it might prevent exploiting a bug in the terminal emulator. So hypothetically speaking, you have a profile for tor-arm, we would probably use it as well.] >> 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. :) Ah, I see. :) > >> --- 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? > > Yup, I don't see why this wouldn't work. Awesome! Cheers, Patrick _______________________________________________ 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.
