anonym: > Patrick Schleizer: >> anonym: >> About the packaging. If you like the genmkfile way to package things, I >> could also do the packaging. Only disadvantage would be an extra >> dependency on genmkfile. >> >> https://github.com/Whonix/control-port-filter-python >> https://github.com/Whonix/genmkfile >> >> That would be trivial on my side since Tails control filter seems very >> similar to control-port-filter-python. (control-port-filter-python >> packaged with genmkfile is a lintian --pedantic warning free and to my >> knowledge, fully complaint Debian source and binary package.) Otherwise, >> I'd just wait for you. > > Sure! I bet you'll beat me to it, so I don't want to be the blocker, but > perhaps I'll take over the packaging in the future, depending on how > things go (would this make sense to include in Debian?). However, first > we need, in order:
Not sure if upload to Debian would benefit any of our projects or if anyone besides our two projects would be interested in that package. Due to release cycles, I guess we'd end up not using that package in Tails/Whonix anyhow. I must admit, that this chance to get genmkfile into Debian as a byproduct is more appealing than the filter itself. If any other of Whonix's packages seems useful to be uploaded to Debian or otherwise useful for Tails, I'd be happy to polish them if there are any requests to return the favor and to improve the cooperation. > 1. A name that doesn't including 'tor'. What about 'grater' or > 'onion-grater'? My inspiration is something like [0]. :) Otherwise > there's 'onion-filter' I guess. What about control-port-filter-python? :) I was rethinking this. The packaging may not be that important on the Whonix side. Since the tails filter is small, clean, nice and simple and "quite similar" to currently used control-port-filter-python... I could just copy over the tails filter to control-port-filter-python usr/sbin/cpfpd. (Along with some minor things such as debian/control migrating dependencies list and systemd unit file differences.) > 2. A dedicated Git repo (trivial once we have a name). https://github.com/Whonix/control-port-filter-python ? :) The separate upstream tails filter repository would just help me to stay on top of changes rather than following changes in the huge Tails main repository. It's not very important either. If you'd ever find a security critical issue, please notify me. Otherwise for newer features, I'll probably learn about them early enough. >> I added 'Flags=DiscardPK', which works and I thought that is useful at >> least in case of Whonix. The workstation does not need to learn the >> hidden service key since onionshare does not use it anyhow. Not sure >> this (and the following) makes also sense in Tails? >> >> Some lines in Tor's response contain the following: >> (azazazazazazaz10 is the HS) >> >> 650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN gliberrish REPLICA=0 >> 650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN gliberrish REPLICA=1 >> 650 HS_DESC UPLOAD azazazazazazaz10 UNKNOWN gliberrish gliberrish >> 650 HS_DESC UPLOADED azazazazazazaz10 UNKNOWN gliberrish >> >> Could you please show how to rewrite them to: >> >> 650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN dedacted REPLICA=0 >> 650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN dedacted REPLICA=1 >> 650 HS_DESC UPLOAD azazazazazazaz10 UNKNOWN dedacted dedacted >> 650 HS_DESC UPLOADED azazazazazazaz10 UNKNOWN dedacted >> >> I am not sure stem would complain about this, but I guess not > > onionshare uses stem's `create_ephemeral_hidden_service()` convenience > method with `await_publication=True`, and it tracks the state of the > hidden services publication via HS_DESC events, so you have to be > careful here (e.g. only allowing the UPLOADED won't work, probably). > > So, to me it looks like you need the following (untested) config, > although you might want to study the spec to see which events are to be > expected: > > HS_DESC: > - pattern: '650 HS_DESC CREATED (\S+) (\S+) (\S+) \S+ (.+)' > replacement: '650 HS_DESC CREATED {} {} {} redacted {}' > - pattern: '650 HS_DESC UPLOAD (\S+) (\S+) .*' > replacement: '650 HS_DESC UPLOAD {} {} redacted redacted' > - pattern: '650 HS_DESC UPLOADED (\S+) (\S+) .+' > replacement: '650 HS_DESC UPLOADED {} {} redacted' > - pattern: '.*' > replacement: '' That unfortunately does not work. user@host:~/tcpfp$ ./tor-controlport-filter --listen-address 0.0.0.0 --debug Tor control port filter started, listening on 0.0.0.0:9051 10.137.11.80:51904 (filter: whonix) connected: loaded filter: whonix Final rules: commands: ADD_ONION: - {pattern: 'NEW:BEST Port=80,(176[0-5][0-9])', replacement: 'NEW:BEST Port=80,{client-address}:{} Flags=DiscardPK'} DEL_ONION: - {pattern: .+} GETCONF: - {pattern: (__owningcontrollerprocess)} GETINFO: - {pattern: circuit-established} - {pattern: status/circuit-established} - pattern: net/listeners/socks response: - {pattern: 250-net/listeners/socks=".*", replacement: '250-net/listeners/socks="127.0.0.1:9150"'} - {pattern: version} - {pattern: onions/current} SIGNAL: - {pattern: NEWNYM} events: CONF_CHANGED: {suppress: true} HS_DESC: - {pattern: 650 HS_DESC CREATED (\S+) (\S+) (\S+) \S+ (.+), replacement: '650 HS_DESC CREATED {} {} {} redacted {}'} - {pattern: 650 HS_DESC UPLOAD (\S+) (\S+) .*, replacement: '650 HS_DESC UPLOAD {} {} redacted redacted'} - {pattern: 650 HS_DESC UPLOADED (\S+) (\S+) .+, replacement: '650 HS_DESC UPLOADED {} {} redacted'} - {pattern: .*, replacement: ''} SIGNAL: {suppress: true} restrict-stream-events: false 10.137.11.80:51904 (filter: whonix): -> PROTOCOLINFO 1 10.137.11.80:51904 (filter: whonix): <- 250-PROTOCOLINFO 1 10.137.11.80:51904 (filter: whonix): <- 250-AUTH METHODS=NULL 10.137.11.80:51904 (filter: whonix): <- 250-VERSION Tor="0.2.8.9 (git-cabd4ef300c6b3d6)" 10.137.11.80:51904 (filter: whonix): <- 250 OK 10.137.11.80:51904 (filter: whonix): -> AUTHENTICATE 10.137.11.80:51904 (filter: whonix): <- 250 OK 10.137.11.80:51904 (filter: whonix): -> SETEVENTS SIGNAL CONF_CHANGED 10.137.11.80:51904 (filter: whonix): suppressed subscription to event 'SIGNAL' 10.137.11.80:51904 (filter: whonix): suppressed subscription to event 'CONF_CHANGED' 10.137.11.80:51904 (filter: whonix): <- 250 OK 10.137.11.80:51904 (filter: whonix): -> GETCONF __owningcontrollerprocess 10.137.11.80:51904 (filter: whonix): <- 250 __OwningControllerProcess 10.137.11.80:51904 (filter: whonix): -> GETINFO version 10.137.11.80:51904 (filter: whonix): <- (multi-line) 250-version=0.2.8.9 (git-cabd4ef300c6b3d6) 250 OK 10.137.11.80:51904 (filter: whonix): -> SETEVENTS HS_DESC SIGNAL CONF_CHANGED 10.137.11.80:51904 (filter: whonix) disconnected: client quit ---------------------------------------- Exception happened during processing of request from ('10.137.11.80', 51904) Traceback (most recent call last): File "/usr/lib/python3.4/socketserver.py", line 613, in process_request_thread self.finish_request(request, client_address) File "/usr/lib/python3.4/socketserver.py", line 344, in finish_request self.RequestHandlerClass(request, client_address, self) File "/usr/lib/python3.4/socketserver.py", line 669, in __init__ self.handle() File "./tor-controlport-filter", line 574, in handle restrict_stream_events File "./tor-controlport-filter", line 456, in handle_controlport_session update_event_subscriptions(events) File "./tor-controlport-filter", line 393, in update_event_subscriptions if not rule.get('suppress', False) or \ AttributeError: 'list' object has no attribute 'get' ---------------------------------------- > However, I saw something in the stem code that might indicate it > actually uses the value you want to redact, but I might be mistaken. I would not be too surprised if padding needs to be added. I.e. fake values need to have compatible string lengths. Perhaps stem checks if the string lengths make sense or stores these values for further use. I however don't think it "really" needs them for onionshare functionality so fake values may work. Will check once the config is working. Cheers, Patrick _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
