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

Patrick Schleizer:
> anonym:
>> [...]
>> Yesterday's patch was trash. See the new commit(s) I've just pushed to
>> the branch.
>
> That seems to work! :)

Woo!

> When the filter is terminated, onionshare apparently does not notice
> that. Would be better if onionshare would notice that. Is that a bug?

It seems like a "bug" in onionshare, or even the control port language
protocol itself since it (AFAICT) doesn't have a concept of the server
quitting mid-session. No signal is sent, and I haven't even found an
event one can explicitly subscribe to to learn when it shuts down. In
fact, any stem-application will, for instance, notice that Tor closed
its control port on the next send() or recv() on the socket, and then
throw a stem.SocketClosed.

> 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:

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.

2. A dedicated Git repo (trivial once we have a name).

[0] http://howto.gd/pic/69/01/03.jpg

> 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: ''

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.

> and seems useful to me be to contain that information.

Sure!

Cheers!