procmem@???:
> Re-sending this in a human readable form:
Thanks!
> A couple of months ago I was looking at locking down the amount of info leaked to Tor Browser in case it is compromised - if/when stream events access is enabled. my thought was to have the cake and eat it too.
I guess you are not considering the restrict-stream-events option since this is in a Whonix context?
> stream-events are needed to supported auth onions IIRC.
Also the circuit view.
> I ran into issues with escaping characters from Tor's output namely $ and + which were included in an example output:
>
> 250+circuit-status=00 BUILT $relayid~$relayid,$relayid~$relayid,$relayid~$relayid BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2020-09-16T00:00:00.000000
>
> Questions:
>
> * Can onion-grater currently deal with such characters without having to escape them?
Du you mean if you can write a pattern (i.e. regexp) where you want to match + and $ (from Tor's output) without escaping them? If so the answer is no, escaping is the only mechanism, and my question for you is why? What's the problem with escaping? For instance, "pattern: '250\+circuit-status…" should work just fine.
I feel like I don't understand your question at all. :/
> * Is it even possible to sanitize responses as large and varied as stream-events output without having something leak thru or is it best to keep it blocked for peace of mind?
Theoretically, I think yes, but any black-list approach is pretty much futile to get perfect unless you put unreasonable resources on maintaining it. So at best you it can be considered in a defense-in-depth approach, but not as a single defense, IMHO.
> The rule I used in the profile:
>
>
> GETINFO:
> - pattern: 'circuit-status'
> response:
> - pattern: '250(.+)circuit-status=(\S+) (\S+) (.+) (\S+) (\S+)'
> - replacement: '250+circuit-status='
This rule is buggy! The fix is to remove the "-" before "replacement". I spotted this issue thanks to the debug log where it is clearer:
> host onion-grater[8471]: - pattern: circuit-status
> host onion-grater[8471]: response:
> host onion-grater[8471]: - {pattern: 250(.+)circuit-status=(\S+) (\S+) (.+) (\S+) (\S+)}
> host onion-grater[8471]: - {replacement: 250+circuit-status=}
As you can see, the 'pattern' and 'replacement' keys are in separate dictionaries, but 'response' wants a list (in your case of length 1) of dictionaries with exactly those two keys present. It becomes a bit more apparent if you provide more than one rewrite rules:
GETINFO:
- pattern: 'circuit-status'
response:
- pattern: '250(.+)circuit-status=(\S+) (\S+) (.+) (\S+) (\S+)'
replacement: '250+circuit-status='
- pattern: ...
replacement: ...
- pattern: ...
replacement: ...
...
Yeah, onion-grater should do a better job validating that the filters it loads are correct...
Cheers!
