blueprint-freespeech / ricochet-refresh

Anonymous peer-to-peer instant messaging
https://www.ricochetrefresh.net
Other
187 stars 27 forks source link

Read Tor control port/host/passwd from env vars #101

Closed JeremyRand closed 2 years ago

JeremyRand commented 3 years ago

Mostly copied verbatim from fe8f24aad1779cc798926d980f55f81b52f71683; seems to have been accidentally removed in e6f1c194e80c58946b3feeecdb09c795582e5f19 (which was supposed to only remove settings file code, not environment variable code).

With this PR applied, I was able to successfully use Ricochet-Refresh with the system Tor provided by Whonix's anon-ws-disable-stacked-tor package.

morganava commented 3 years ago

Could you first check to see if TOR_SKIP_LAUNCH=1 before checking TOR_SOCKS_HOST et al? What is the observed behavior if any of these parameters are set incorrectly? I suspect errors here are probably not handled gracefully but who knows.

JeremyRand commented 3 years ago

Could you first check to see if TOR_SKIP_LAUNCH=1 before checking TOR_SOCKS_HOST et al?

@pospeselr The specification at https://gitlab.torproject.org/legacy/trac/-/wikis/doc/Tor_friendly_applications_best_practices#network-configuration doesn't actually specify the correct behavior if TOR_SKIP_LAUNCH isn't 1 and TOR_CONTROL_PORT is set. Legacy Ricochet doesn't check TOR_SKIP_LAUNCH at all IIRC. I think I agree that we should properly specify the behavior before merging this, since it's undesirable for different applications (Tor Browser, Ricochet, etc) to have subtly different behavior here.

I've filed this issue over at Tor, which is a prereq for clarifying the spec.

adrelanos commented 2 years ago

It might be helpful to mention the history of how these features really emerged, which was rather unorganized versus what seems to be expected now, which is solid, sophisticated, official standards document.

https://gitlab.torproject.org/legacy/trac/-/wikis/doc/Tor_friendly_applications_best_practices#network-configuration

I was present and contributing when https://gitlab.torproject.org/legacy/trac/-/wikis/doc/Tor_friendly_applications_best_practices when was written a few years ago in old Tor Project trac wiki where anyone could edit and where there was minimal oversight by The Tor Project. It was at the 33c3 conference or so and an effort by Tails developers as well as me and whoever else eludes me since this is a long time ago. Can be considered thoughts by the Tor community. Top of the wiki page is saying UNFINISHED DRAFT! so don't take it was an official guideline by The Tor Project.

The Tor Project never really vetted, modified, adopted the draft and made it their own speech.

I've filed this issue over at Tor, which is a prereq for clarifying the spec.

No reply for 4 months and I doubt there will be a reply anytime soon.

doesn't actually specify the correct behavior if TOR_SKIP_LAUNCH isn't 1 and TOR_CONTROL_PORT is set.

These features have been independently developed, contributed to Tor Browser without "master plan".

If I remember right, TOR_SKIP_LAUNCH came first for people who where running system Tor locally and providing all the ports (SocksPort 9150 and ControlPort 9151) that Tor Browse was requiring at the time. TOR_SOCKS_HOST was added later for people who do the same but on a different computer in their LAN.

Setting sensible environment variables values is really up to advanced users and/or distributions such as Whonix or Tails.

Could you first check to see if TOR_SKIP_LAUNCH=1 before checking TOR_SOCKS_HOST et al?

Given the history, this isn't in the "specification" since there really isn't a specification. The closest thing to the canonical behavior would the behavior of the Tor Browser Bundle which doesn't check TOR_SKIP_LAUNCH versus TOR_SOCKS_HOST being sensible.

What is the observed behavior if any of these parameters are set incorrectly?

Tor Browser does as instructed and doesn't sanity test these settings.

morganava commented 2 years ago

So I'm trying to do as little code churn in Ricochet-Refresh as possible until the backend is replaced with Gosling. We have a ticket tracking this sort of thing here: https://github.com/blueprint-freespeech/gosling/issues/5

adrelanos commented 2 years ago

I don't understand.

Gosling is a protocol specification. But how Ricochet handles Tor transparent / isolating proxies or anonymity focussed operating systems wouldn't really be part of the protocol specification?

Since this patch doesn't change the default behavior, could you please merge it? Or merge the patch and then work the way backwards and document it in the protocol later if it's part of it?

morganava commented 2 years ago

Protocol specification and reference implementation.

As I said, I have very little interest in adding and maintaining any more functionality to the current Ricochet-Refresh backend.

For reference, the right place to put this (or similar) functionality will be in Gosling here (which is under active development):