Suggestion: Focus on the Service. Do not include Tor.

[DiagonalArg]

Thanks for taking up this project. While I'm not much of a developer, I can see that ricochet includes Tor, which is a fine way to make sure it becomes rapidly obsolete. I wonder if you would want to focus only on the task of creating the service, which would then be linked to an already running Tor service?

[Edit] I'm just discovering that there is such thing as an "ephemeral onion services" and that onionshare/onionize are using it. Perhaps that's the way to go with ricochet? Here is a description.

References - ricochet-im and @cypherbits

[eleanor-em]

I absolutely agree and I think including a build is not the best way to go about it. Will definitely check out this ephemeral onion service business!

[cypherbits]

As I said on main ricochet:
The goal of including Tor with Ricochet is that people with no system-wide Tor, like Windows users can use Ricochet easily. Ephemeral onion services make easy for Ricochet to manage many identities but you need Tor to connect to Tor xD

[DiagonalArg]

I'll just refer to my comment there.

[PeterTonoli]

I feel this is a usability issue. While you & I might have the nous to update Tor, some of Ricochet's users might not.

Regular updates of Ricochet will mitigate this problem.

Please include Tor.

[DiagonalArg]

Well, if you want to go that way, I'd modify that to say "Please include tor only if the developer intends to update ricochet/ricochet-refresh every time tor updates." Otherwise, it's just making it easy for users to screw up.

[timkuijsten]

The original Ricochet simply looks for a system-wide version of Tor if the included (and by now hopelessly outdated) Tor binary is not there. This helped me maintian Ricochet on all supported platforms remarkably well, as I've documented here: https://netsend.nl/ricochet.

[odiferousmint]

Ephemeral onion service is completely separate from the bundling of Tor. Creating an ephemeral hidden service means that you create a new private key every single time (because it is not saved), which with respect to Ricochet means a new identity. Ricochet saves your private key (i.e. it is not ephemeral) in ricochet.json as serviceKey (inside identity). To use ephemeral hidden service means to create a new identity every time you start Ricochet. In practice it means your Ricochet ID is going to be different, and your contacts will have to re-add you. This does not necessarily have to be the case (you could use BasicAuth and whatnot), but it would require a change in the design and protocol of Ricochet. Right now, as it currently is, it does not seem to be a good thing. That said, I can imagine this as a setting in the future. If you would like to see it as a setting, open a separate issue because it has nothing to do with bundling or not bundling Tor.

As far as bundling Tor goes, there are two ways to customize the Tor executable path: 1) if you are compiling it from source, define BUNDLED_TOR_PATH, or 2) in ricochet.json which Ricochet loads on startup, add:

{
    "tor": {
        "executablePath": "/usr/bin/"
    }
    ...
}

Or just place the Tor executable in the same directory where the Ricochet executable is.

I believe that you are looking for the 2nd option here. If you would like to use your system's Tor executable, set the executablePath in your config file ricochet.json similarly to my example above. That way, if you update Tor, you will have nothing to do.

FWIW: I think that defaulting to using ./tor or ./tor.exe is optimal, and Tor should be bundled because if you do not bundle Tor, you rely on having it installed by someone under the default or customized Tor executable path, which is extra work, and it will not work out-of-the-box, which I believe is an issue for a lot of people. As Peter has said, "regular updates of Ricochet will mitigate this problem", or you might as well just set the executable path yourself and/or update Tor yourself. It is a non-issue.

[DiagonalArg]

Ephemeral onion service is completely separate from the bundling of Tor.

If tor is running as a daemon, then this will allow you to start a service through the already running tor. I understand what you are saying above and have already opened another issue that can be taken to be on this question of using ephemeral services.

two ways to customize the Tor executable path: ... 2) in ricochet.json which Ricochet loads on startup, add ... [above]

Thank you, that's useful.

FWIW: I think that defaulting to using ./tor or ./tor.exe is optimal,

That's fine, if you want a tor specifically running for ricochet.

and Tor should be bundled because if you do not bundle Tor, you rely on having it installed by someone under the default or customized Tor executable path, which is extra work, and it will not work out-of-the-box, which I believe is an issue for a lot of people.

That is also fine if:

As Peter has said, "regular updates of Ricochet will mitigate this problem",

On the other hand, the fact is that there have not been regular updates of Ricochet - far from it. So if Ricochet is regularly updated, then bundling tor might make sense as it makes it easy for people who don't know how to install it. On the other hand, if Ricochet is not regularly updated, which is absolutely the case, then bundling tor makes it easy for people who don't know how to install it to shoot themselves in the foot. So if you don't want people shooting themselves in the foot, and you are not going to update Ricochet immediately every time tor is updated, then you won't bundle tor with it. (That's a logical tautology - check it.)

or you might as well just set the executable path yourself and/or update Tor yourself. It is a non-issue.

There we disagree. Unless updates happen immediately on update of tor, you will be seducing people who don't know what they are doing into thinking they are safe.

[odiferousmint]

If tor is running as a daemon, then this will allow you to start a service through the already running tor.

Yeah, but this has nothing to do with ephemerality. We could check if there is a daemon already running, but I would rather prefer Ricochet to start its own instance with its own Tor configuration file as it currently does. You do not necessarily control the Tor configuration file that the system-wide Tor daemon uses, and it poses other risks as well.

FWIW: I think that defaulting to using ./tor or ./tor.exe is optimal

That's fine, if you want a tor specifically running for ricochet.

I am not sure what you mean by this. Ricochet can just as well use any other Tor executable to start its own daemon with its (Ricochet's) own configuration file. It does not matter whether it is /usr/bin/tor or ./tor.

On the other hand, if Ricochet is not regularly updated, which is absolutely the case, then bundling tor makes it easy for people who don't know how to install it to shoot themselves in the foot. So if you don't want people shooting themselves in the foot, and you are not going to update Ricochet immediately every time tor is updated, then you won't bundle tor with it. (That's a logical tautology - check it.)

People who do not know how to install and/or update Tor will not be able to use Ricochet, because it depends on Tor. Just for clarification, are you suggesting that this should be the case?

you will be seducing people who don't know what they are doing into thinking they are safe

OK, what can we do about this right now, as people who have no write access to the project? We can note somewhere that the current version of the bundled Tor is outdated, we can add instructions as to how to update Tor, and we can tell users the same thing I told you regarding Tor executable path customization. We should also note that updating Tor is not enough. Ricochet needs to switch from RSA1024 to ED25519-V3 at the very least.

In any case, you are saying that Ricochet should not bundle Tor because it (Ricochet) is not regularly updated. What you are asking here is for developers to make a change to Ricochet, i.e. update Ricochet. If they are going to do that, they might as well just continue bundling Tor (there are not that many releases of the part of Tor on which Ricochet depends) and update the version, along with adding instructions as to how to update Tor, inform users about everything I said regarding setting the Tor executable path, and about the current security concerns. Additionally, you do not necessarily have to update Tor all the time, and again, there are not too many releases anyway[1], or at least it does not happen as frequently as you may think.

By the way, I would like to withdraw my statement regarding defaulting to ./tor and ./tor.exe being the optimal choice. If tor.executablePath is not set, on Linux and macOS (?) we should default to /usr/bin/ and /usr/local/bin/, and if the executable was not found, try ./tor, but this requires the Tor executable to be bundled, otherwise you will not be able to use Ricochet. On Windows we could default to wherever it is typically installed and a few other alternative paths, and if the executable was not found, try ./tor.exe.

[1] https://dist.torproject.org/

[morganava]

Tor is bundled in alpha builds, uses ephemeral onion services and has made the switch to E25519-V3 based onion services. We do need a good plan for UX (and backend work) for specifying whether to use an existing running system tor service, and whether to launch a new instance of the system tor or the bundled tor. Currently ricochet-refresh launches its own bundled tor.