Add a warning to the Ricochet description #474

New Issue

2018-05-29T07:10:35Z

ghost commented

2018-05-29 07:10:35 +00:00

(Migrated from github.com)

https://github.com/ricochet-im/ricochet/issues/579

It's already dead.

https://github.com/ricochet-im/ricochet/issues/579 It's already dead.

👍 1 👎 1

ilovelinux commented

2018-05-29 14:07:23 +00:00

(Migrated from github.com)

It's not dead. As I answered to you in the issue you referenced and in https://github.com/ricochet-im/ricochet/issues/578, Ricochet is sicure and development is still going on. There are no reasons to remove it from "Encrypted Instant Messanger".

👎 1

ghost commented

2018-05-29 23:40:46 +00:00

(Migrated from github.com)

@ilovelinux Are you blind? You are not a ricochet developer anyway. Read.

ghost commented

2018-06-04 07:23:56 +00:00

(Migrated from github.com)

Related website, prism-break.org, removed Ricochet. What about you?

https://github.com/nylira/prism-break/issues/1975

Related website, prism-break.org, removed Ricochet. What about you? https://github.com/nylira/prism-break/issues/1975

👍 1

ghost commented

2018-11-13 16:55:28 +00:00

(Migrated from github.com)

I don't think this should be removed as there's nothing to cause reason that it does not work. The security of this mostly uses Tor Hidden Services. Perhaps a warning about making sure that you're using the latest version of Tor and not the bundled binary would be helpful.

The program did undergo an audit in 2016.

It is inevitable that more complex clients such as the proprietary options are going to be able to support other features at the cost of security. It's probably the best choice for avoiding metadata collection at this point in time. Not everyone needs A/V, server side logs, multi-device etc.

Perhaps we could keep an eye on https://redmine.tails.boum.org/code/issues/8173

I don't think this should be removed as there's nothing to cause reason that it does not work. The security of this mostly uses Tor Hidden Services. Perhaps a warning about making sure that you're using the latest version of Tor and not the bundled binary would be helpful. The program did [undergo an audit in 2016](https://ricochet.im/files/ricochet-ncc-audit-2016-01.pdf). It is inevitable that more complex clients such as the proprietary options are going to be able to support other features at the cost of security. It's probably the best choice for avoiding metadata collection at this point in time. Not everyone needs A/V, server side logs, multi-device etc. Perhaps we could keep an eye on https://redmine.tails.boum.org/code/issues/8173

ghost commented

2018-11-14 23:24:28 +00:00

(Migrated from github.com)

I second that we should add a notice regarding using a new version of Tor. I think the only publicly known vulns in the main ricochet client right now are just in the Tor version it uses.

👍 1

ghost commented

2018-11-24 09:26:57 +00:00

(Migrated from github.com)

👍 Can anyone create a PR adding what @beardog108 mentioned?

:+1: Can anyone create a PR adding what @beardog108 mentioned?

ghost commented

2018-11-25 11:02:22 +00:00

(Migrated from github.com)

How does this look:

How does this look: ![warning-ricochet](https://user-images.githubusercontent.com/42108382/48978307-8e252500-f0a1-11e8-8726-c526e4197578.png)

ghost commented

2018-11-25 11:19:02 +00:00

(Migrated from github.com)

Looks good! The only change I'd make is: [icon]See below -> See below: [icon] Updating the Tor binary included with Ricochet.

So: [Danger] Always keep Tor up to date. See below: [icon] Updating the Tor binary included with Ricochet

And maybe add a command to copy it on Linux and OS X? Hm, maybe a symlink would be better, because updating Tor browser would update the binary for Ricochet as well? And can't the tor binary location be changed in Ricochet's settings? It feels kinda hacky to copy the binary.

The symlink command would look like this:

$ mv ~/Downloads/ricochet/tor ~/Downloads/ricochet/tor.old
$ ln -s ~/Downloads/tor-browser_en-US/Browser/TorBrowser/Tor/tor ~/Downloads/ricochet/tor

Looks good! The only change I'd make is: <code><a href="#">[icon]See below</a></code> -> <code>See below: <a href="#">[icon] Updating the Tor binary included with Ricochet</a></code>. So: `[Danger]` <strong>Always keep Tor up to date. See below: <a href="#">[icon] Updating the Tor binary included with Ricochet</a></strong> And maybe add a command to copy it on Linux and OS X? Hm, maybe a symlink would be better, because updating Tor browser would update the binary for Ricochet as well? And can't the tor binary location be changed in Ricochet's settings? It feels kinda hacky to copy the binary. The symlink command would look like this: ```sh $ mv ~/Downloads/ricochet/tor ~/Downloads/ricochet/tor.old $ ln -s ~/Downloads/tor-browser_en-US/Browser/TorBrowser/Tor/tor ~/Downloads/ricochet/tor ```

ghost commented

2018-11-25 11:51:02 +00:00

(Migrated from github.com)

Looks good! The only change I'd make is: [[icon] See below](#) -> See below: [[icon] Updating the Tor binary included with Ricochet](#).

So: [Danger] Always keep Tor up to date. See below: [icon] Updating the Tor binary included with Ricochet

Easy done.

And maybe add a command to copy it on Linux and OS X? Hm, maybe a symlink would be better, because updating Tor browser would update the binary for Ricochet as well? And can't the tor binary location be changed in Ricochet's settings? It feels kinda hacky to copy the binary.

It would be better to delete the Tor binary included with Ricochet as there's absolutely no reason to use an old vulnerable version of Tor. It would be better for Ricochet to not open than to risk it using a vulnerable version of Tor.

For MacOSX and Linux it should be sufficient to just "delete" the bundled Tor binary as long as Tor is in the $PATH. Ricochet then will fallback to the binary in the $PATH.

I would do this by using the rm command and using sed to append the path from the Tor Browser's Tor binary to the user's profile $PATH. From the README included in the Linux release:

You do not need to manually run or configure tor. An unmodified tor binary
is included with this package, and Ricochet will run it automatically,
similiar to Tor Browser. There isn't any option to use a system tor daemon,
but Ricochet will use the tor binary from PATH if the bundled copy is removed.

There doesn't seem to be a way within the configuration file or within the user interface to change the location of where the Tor binary is located. On Windows it seems that it's hard coded. I think copying it will be the only solution for Windows without making changes to the Ricochet source.

See: https://github.com/ricochet-im/ricochet/blob/master/src/tor/TorManager.cpp#L274

Does this seem like an acceptable solution to you?

> Looks good! The only change I'd make is: `[[icon] See below](#)` -> `See below: [[icon] Updating the Tor binary included with Ricochet](#)`. > > So: `[Danger]` **Always keep Tor up to date. See below: [[icon] Updating the Tor binary included with Ricochet](#)** Easy done. > And maybe add a command to copy it on Linux and OS X? Hm, maybe a symlink would be better, because updating Tor browser would update the binary for Ricochet as well? And can't the tor binary location be changed in Ricochet's settings? It feels kinda hacky to copy the binary. It would be better to **delete** the Tor binary included with Ricochet as there's **absolutely no reason** to use an old vulnerable version of Tor. It would be better for Ricochet to **not open** than to risk it using a vulnerable version of Tor. For MacOSX and Linux it should be sufficient to just "delete" the bundled Tor binary as long as Tor is in the `$PATH`. Ricochet then will fallback to the binary in the `$PATH`. I would do this by using the `rm` command and using `sed` to append the path from the Tor Browser's Tor binary to the user's profile `$PATH`. From the README included in the Linux release: > You do not need to manually run or configure tor. An unmodified tor binary > is included with this package, and Ricochet will run it automatically, > similiar to Tor Browser. There isn't any option to use a system tor daemon, > but Ricochet will use the tor binary from PATH if the bundled copy is removed. There doesn't seem to be a way within the configuration file or within the user interface to change the location of where the Tor binary is located. On Windows it seems that it's hard coded. I think copying it will be the only solution for Windows without making changes to the Ricochet source. See: https://github.com/ricochet-im/ricochet/blob/master/src/tor/TorManager.cpp#L274 Does this seem like an acceptable solution to you?

ghost commented

2018-11-25 12:30:07 +00:00

(Migrated from github.com)

Great. Since it has a fallback to PATH, there's no need to create symlinks. ~~Though which tor is part of PATH? The one from the browser? The one installed using apt(-get) for example? If the latter then~~ it should be noted that updating Tor Browser won't update the other tor (likely).

On my OS, there's:

a) /home/ubuntu/tor-browser_en-US/Browser/TorBrowser/Tor/tor
b) /usr/sbin/tor -> /usr/bin/tor

For me, tor is the one in sbin.

$ which tor
/usr/sbin/tor

I would do this by using the rm command

Maybe mv foo foo.old is better since if the following commands don't work / break something, there will still be a recoverable (though potentially insecure) backup without having to reinstall Ricochet.

Great. Since it has a fallback to PATH, there's no need to create symlinks. <strike>Though which `tor` is part of PATH? The one from the browser? The one installed using `apt(-get)` for example? If the latter then</strike> it should be noted that updating Tor Browser won't update the other tor (likely). On my OS, there's: a) `/home/ubuntu/tor-browser_en-US/Browser/TorBrowser/Tor/tor` b) `/usr/sbin/tor` -> `/usr/bin/tor` For me, `tor` is the one in sbin. ```sh $ which tor /usr/sbin/tor ``` > I would do this by using the `rm` command Maybe `mv foo foo.old` is better since if the following commands don't work / break something, there will still be a recoverable (though potentially insecure) backup without having to reinstall Ricochet.

ghost commented

2018-11-25 12:46:36 +00:00

(Migrated from github.com)

When referring to using rm on the Linux platform I meant to delete ricochet/tor assuming they installed it from ricochet-1.1.4-linux-x86_64.tar.bz2.

If you installed Ricochet through apt-get you're going to find that it doesn't include Tor and will depend on it instead. The maintainer will keep that up to date.

On my OS, there's:

a) /home/ubuntu/tor-browser_en-US/Browser/TorBrowser/Tor/tor
b) /usr/sbin/tor -> /usr/bin/tor

Unless 'a' i in your path it's never going to be found. 'b' would be used. As /usr/bin and /usr/sbin are in your path whatever is first in your $PATH would get used. You'd have to put ~/tor-browser_en-US/Browser/TorBrowser/Tor/tor first.

I suppose it would just be safer to make a symlink ie ln -s ~/tor-browser_en-US/Browser/TorBrowser/Tor/tor ~/ricochet/tor then we don't have to worry about if they've installed Tor through apt-get.

It's fairly safe to assume on MacOSX that the Tor binary will be in Applications assuming the user dragged the .app into their /Applications directory ie.

/Applications/Ricochet.app/Contents/MacOS/tor
/Applications/Tor Browser.app/Contents/Resources/TorBrowser/Tor/tor

When referring to using `rm` on the Linux platform I meant to delete `ricochet/tor` assuming they installed it from `ricochet-1.1.4-linux-x86_64.tar.bz2`. If you installed [Ricochet through apt-get](https://packages.debian.org/stretch/amd64/ricochet-im/filelist) you're going to find that it doesn't include [Tor](https://packages.debian.org/stretch/tor) and will depend on it instead. The maintainer will keep that up to date. > On my OS, there's: > > a) `/home/ubuntu/tor-browser_en-US/Browser/TorBrowser/Tor/tor` > b) `/usr/sbin/tor` -> `/usr/bin/tor` Unless 'a' i in your path it's never going to be found. 'b' would be used. As `/usr/bin` and `/usr/sbin` are in your path whatever is first in your `$PATH` would get used. You'd have to put `~/tor-browser_en-US/Browser/TorBrowser/Tor/tor` first. I suppose it would just be safer to make a symlink ie `ln -s ~/tor-browser_en-US/Browser/TorBrowser/Tor/tor ~/ricochet/tor` then we don't have to worry about if they've installed Tor through apt-get. It's fairly safe to assume on MacOSX that the Tor binary will be in `Applications` assuming the user dragged the .app into their `/Applications` directory ie. `/Applications/Ricochet.app/Contents/MacOS/tor` `/Applications/Tor Browser.app/Contents/Resources/TorBrowser/Tor/tor`

ghost commented

2018-11-25 14:35:56 +00:00

(Migrated from github.com)

When referring to using rm on the Linux platform I meant to delete ricochet/tor assuming they installed it from ricochet-1.1.4-linux-x86_64.tar.bz2.

I meant to keep a copy of the tor version that ricochet uses. Just a small detail, not important.

> When referring to using rm on the Linux platform I meant to delete ricochet/tor assuming they installed it from ricochet-1.1.4-linux-x86_64.tar.bz2. I meant to keep a copy of the tor version that ricochet uses. Just a small detail, not important.

TNTBOMBOM commented

2019-01-23 15:01:53 +00:00

(Migrated from github.com)

better removing ricochet is outdated as hell and there are many bugs inside it and Tor new versions not supported by it. Wonder why the hell its still hanging there.

ghost commented

2019-01-23 18:04:56 +00:00

(Migrated from github.com)

better removing ricochet is outdated as hell

It still works, does it not? It also has been audited by NCC.

and there are many bugs inside it

Such as? All software has bugs, this is not sufficient reason to remove it. If we did that we would have nothing left. Unless they are directly related to security and are not fixed, as in do X de-anonymise user Y. Considering anonymity is one of Ricochet's selling points vs other messengers.

and Tor new versions not supported by it.

My understanding was it still worked with Hidden Services v2 does it not? Documentation was being improved to instruct how to replace the binary with a newer version.

Wonder why the hell its still hanging there.

Is there something better that uses HiddenServices? On a side note, I am curious about https://cwtch.im however it is still firmly experimental at the moment.

> better removing ricochet is outdated as hell It still works, does it not? It also has been audited by NCC. > and there are many bugs inside it Such as? All software has bugs, this is not sufficient reason to remove it. If we did that we would have nothing left. Unless they are directly related to security and are not fixed, as in do X de-anonymise user Y. Considering anonymity is one of Ricochet's selling points vs other messengers. > and Tor new versions not supported by it. My understanding was it still worked with Hidden Services v2 does it not? Documentation was being improved to instruct how to replace the binary with a newer version. > Wonder why the hell its still hanging there. Is there something better that uses HiddenServices? On a side note, I am curious about https://cwtch.im however it is still firmly experimental at the moment.

TNTBOMBOM commented

2019-01-23 20:37:12 +00:00

(Migrated from github.com)

It still works, does it not? It also has been audited by NCC.

working with dying soul. i dunno what kind of a joke of audition is this.

Such as? All software has bugs, this is not sufficient reason to remove it. If we did that we would have nothing left. Unless they are directly related to security and are not fixed, as in do X de-anonymise user Y. Considering anonymity is one of Ricochet's selling points vs other messengers.

yeah but bugs in this case wont fix inside ricochet stuff from 2011 ... example im facing chat deletion,contact removal issue, tor not updated and 2.x has alot of horrible hidden services issues... no way to be considered reliable. Good replacement is Tox Chat.

My understanding was it still worked with Hidden Services v2 does it not? Documentation was being improved to instruct how to replace the binary with a newer version.

yes hidden services v2 still working with Tor 3.x, but the issue when you are using Tor 2.x and using onion v2 = thats fucked.

Is there something better that uses HiddenServices? On a side note, I am curious about https://cwtch.im however it is still firmly experimental at the moment.

nope. and cwtch im sure wont be much.

> It still works, does it not? It also has been audited by NCC. working with dying soul. i dunno what kind of a joke of audition is this. > Such as? All software has bugs, this is not sufficient reason to remove it. If we did that we would have nothing left. Unless they are directly related to security and are not fixed, as in do X de-anonymise user Y. Considering anonymity is one of Ricochet's selling points vs other messengers. yeah but bugs in this case wont fix inside ricochet stuff from 2011 ... example im facing chat deletion,contact removal [issue](https://github.com/ricochet-im/ricochet/issues/593), tor not updated and 2.x has alot of horrible hidden services issues... no way to be considered reliable. Good replacement is [Tox Chat](https://tox.chat/). > My understanding was it still worked with Hidden Services v2 does it not? Documentation was being improved to instruct how to replace the binary with a newer version. yes hidden services v2 still working with Tor 3.x, but the issue when you are using Tor 2.x and using onion v2 = thats fucked. > Is there something better that uses HiddenServices? On a side note, I am curious about https://cwtch.im however it is still firmly experimental at the moment. nope. and cwtch im sure wont be much.

ghost commented

2019-01-24 03:59:31 +00:00

(Migrated from github.com)

working with dying soul. i dunno what kind of a joke of audition is this.

You're welcome to check out the code and make some of the improvements you desire. I'm sure your PRs will be appreciated. Also Ricochet Security Assessment February 15, 2016 – Version 1.2.

yeah but bugs in this case wont fix inside ricochet stuff from 2011 ... example im facing chat deletion,contact removal issue,

The bug poster hasn't provided enough information, see my reply https://github.com/ricochet-im/ricochet/issues/593#issuecomment-457061221.

Maybe you could do that instead of running around purporting to be a Whonix developer when you're not and have made no commits to the project.

tor not updated and 2.x has alot of horrible hidden services issues... no way to be considered reliable.

You could pay for a bug bounty. That would certainly encourage someone to move a bit faster in completing https://github.com/ricochet-im/ricochet/issues/575

tor not updated and 2.x has alot of horrible hidden services issues... no way to be considered reliable. Good replacement is Tox Chat.

Considering the authors of Tox clearly state it is experimental it cannot in good faith be recommended anything more than as experimental at this point. In particular:

Keep in mind that these clients are alpha software under heavy development, and are probably not ready for day-to-day use. Because of how significantly the code is still changing, a professional audit hasn't yet been started.

What it sets out to do is significantly more complex than Ricochet which mostly leaves the heavy lifting crypto to Tor. I doubt an audit will occur before the documentation (TokTok) is completed. Audits cost a lot of money and are usually done in the final stage of development after protocol design has been stabilized and frozen.

Additionally as I commented in https://github.com/privacytoolsIO/privacytools.io/issues/736#issuecomment-456901644 it has already been added to the website. Looking at your history it seems you have a problem with using the search function (many of your opened issues have been closed as DUPLICATE).

nope. and cwtch im sure wont be much.

Are you a fortune teller?

> working with dying soul. i dunno what kind of a joke of audition is this. You're welcome to check out the code and make some of the improvements you desire. I'm sure your PRs will be appreciated. Also [Ricochet Security Assessment February 15, 2016 – Version 1.2](https://ricochet.im/files/ricochet-ncc-audit-2016-01.pdf). > yeah but bugs in this case wont fix inside ricochet stuff from 2011 ... example im facing chat deletion,contact removal [issue](https://github.com/ricochet-im/ricochet/issues/593), The bug poster hasn't provided enough information, see my reply https://github.com/ricochet-im/ricochet/issues/593#issuecomment-457061221. Maybe you could do that instead of [running around purporting to be a Whonix developer when you're not](https://www.google.com/search?&q=%22im+TNT+BOM+BOM+from+Whonix+community%22 ) and have made no commits to the project. >tor not updated and 2.x has alot of horrible hidden services issues... no way to be considered reliable. You could pay for a bug bounty. That would certainly encourage someone to move a bit faster in completing https://github.com/ricochet-im/ricochet/issues/575 > tor not updated and 2.x has alot of horrible hidden services issues... no way to be considered reliable. Good replacement is [Tox Chat](https://tox.chat/). Considering the [authors of Tox clearly state it is experimental](https://tox.chat/download.html#warning) it cannot in good faith be recommended anything more than as experimental at this point. In particular: > Keep in mind that these clients are alpha software under heavy development, and are probably not ready for day-to-day use. Because of how significantly the code is still changing, a professional audit hasn't yet been started. What it sets out to do is significantly more complex than Ricochet which mostly leaves the heavy lifting crypto to Tor. I doubt an audit will occur before the documentation (TokTok) is completed. Audits cost a lot of money and are usually done in the final stage of development after protocol design has been stabilized and frozen. Additionally as I commented in https://github.com/privacytoolsIO/privacytools.io/issues/736#issuecomment-456901644 it has already been added to the website. Looking at your history it seems you have a problem with using the search function (many of your opened issues have been closed as DUPLICATE). > nope. and cwtch im sure wont be much. Are you a fortune teller?

TNTBOMBOM commented

2019-01-24 15:14:25 +00:00

(Migrated from github.com)

You're welcome to check out the code and make some of the improvements you desire. I'm sure your PRs will be appreciated. Also Ricochet Security Assessment February 15, 2016 – Version 1.2.

not reliable. since the project havent been active since more than 3 years, plus the one who involved there is the same maintainer of Ricochet itself who left it and run away.. (are you kidding me..) .

The bug poster hasn't provided enough information, see my reply ricochet-im/ricochet#593 (comment).
Maybe you could do that instead of running around purporting to be a Whonix developer when you're not and have made no commits to the project.

Anyone whos running ricochet know how sucks its performance and stability (unless the user too blind to see that) , no need logs to prove it. and im just a user of whonix not a developer.

You could pay for a bug bounty. That would certainly encourage someone to move a bit faster in completing ricochet-im/ricochet#575

I wont pay a dollar for a dead project which there are no known maintainers to it anymore.

Considering the authors of Tox clearly state it is experimental it cannot in good faith be recommended anything more than as experimental at this point.

Well maybe you missed that as well in Ricochet main page:

Be careful

Ricochet is an experiment.

So your argument of experimental or not has no value.

Additionally as I commented in #736 (comment) it has already been added to the website. Looking at your history it seems you have a problem with using the search function (many of your opened issues have been closed as DUPLICATE).

And many others wont fix , and many others still open ... so you are not making any sense at all.

Are you a fortune teller?

Yes

> You're welcome to check out the code and make some of the improvements you desire. I'm sure your PRs will be appreciated. Also Ricochet Security Assessment February 15, 2016 – Version 1.2. not reliable. since the project havent been active since more than 3 years, plus the one who involved there is the same maintainer of Ricochet itself who left it and run away.. (are you kidding me..) . > The bug poster hasn't provided enough information, see my reply ricochet-im/ricochet#593 (comment). > Maybe you could do that instead of running around purporting to be a Whonix developer when you're not and have made no commits to the project. Anyone whos running ricochet know how sucks its performance and stability (unless the user too blind to see that) , no need logs to prove it. and im just a user of whonix not a developer. > You could pay for a bug bounty. That would certainly encourage someone to move a bit faster in completing ricochet-im/ricochet#575 I wont pay a dollar for a dead project which there are no known maintainers to it anymore. > Considering the authors of Tox clearly state it is experimental it cannot in good faith be recommended anything more than as experimental at this point. Well maybe you missed that as well in Ricochet [main page](https://ricochet.im/): ``` Be careful Ricochet is an experiment. ``` So your argument of experimental or not has no value. > Additionally as I commented in #736 (comment) it has already been added to the website. Looking at your history it seems you have a problem with using the search function (many of your opened issues have been closed as DUPLICATE). And many others wont fix , and many others still open ... so you are not making any sense at all. > Are you a fortune teller? Yes

ghost commented

2019-01-24 16:05:03 +00:00

(Migrated from github.com)

not reliable. since the project havent been active since more than 3 years, plus the one who involved there is the same maintainer of Ricochet itself who left it and run away.. (are you kidding me..) .

Well unless you can point to some new 0days out there, I think the report from NCC is still valid enough. As far as I am aware the only vulnerabilities relate to the old Tor binary distributed (which can be replaced) and not Ricochet itself.

The bug poster hasn't provided enough information, see my reply https://github.com/ricochet-im/ricochet/issues/593.

Anyone whos running ricochet know how sucks its performance and stability (unless the user too blind to see that) , no need logs to prove it.

That issue you cited had nothing to do with performance. It was a null pointer exception.

Maybe you could do that instead of running around purporting to be a Whonix developer when you're not and have made no commits to the project.

and im just a user of whonix not a developer.

You didn't make any effort to correct people when they assumed you were. Using the name "whonix_anonymous_os" , "Whonix" and their project logo would give off that vibe. When you then suggest things like collaboration, people would assume you had something to do with the project as that would be something for the actual project members to decide. 1, 2, 3, 4

I wont pay a dollar for a dead project which there are no known maintainers to it anymore.

Why don't you become it's maintainer? If there was a bug bounty I'm sure someone would make some improvements. The code isn't all that mystical, it just needs someone's time.

That being said it looks like cwtch.im is getting quite a few commits so this might very well be a healthy fork with some new features. I hope it works out well for them.

Considering the authors of Tox clearly state it is experimental it cannot in good faith be recommended anything more than as experimental at this point.

Well maybe you missed that as well in Ricochet main page:
Be careful
Ricochet is an experiment.
So your argument of experimental or not has no value.

Yes but it's far less drastic than what Tox proposes (own crypto) vs using HiddenServices. I wish them good fortune as well and have used qTox a number of times for video conferencing.

Additionally as I commented in https://github.com/privacytoolsIO/privacytools.io/issues/736 it has already been added to the website. Looking at your history it seems you have a problem with using the search function (many of your opened issues have been closed as DUPLICATE).

And many others wont fix , and many others still open ... so you are not making any sense at all.

And if you'd actually used the search option you'd see that Tox is already on the privacytools.io website like I told you in https://github.com/privacytoolsIO/privacytools.io/issues/736#issuecomment-456901644

Anyway I've wasted enough time on you.

> not reliable. since the project havent been active since more than 3 years, plus the one who involved there is the same maintainer of Ricochet itself who left it and run away.. (are you kidding me..) . Well unless you can point to some new 0days out there, I think the report from NCC is still valid enough. As far as I am aware the only vulnerabilities relate to the old Tor binary distributed (which can be replaced) and not Ricochet itself. >> The bug poster hasn't provided enough information, see my reply https://github.com/ricochet-im/ricochet/issues/593. > Anyone whos running ricochet know how sucks its performance and stability (unless the user too blind to see that) , no need logs to prove it. That issue you cited had nothing to do with performance. It was a null pointer exception. >> Maybe you could do that instead of running around purporting to be a Whonix developer when you're not and have made no commits to the project. > and im just a user of whonix not a developer. You didn't make any effort to correct people when they assumed you were. Using the name "whonix_anonymous_os" , "Whonix" and their project logo would give off that vibe. When you then suggest things like collaboration, people would assume you had something to do with the project as that would be something for the actual project members to decide. [1](https://community.parrotsec.org/t/parrot-sitting-in-whonix-nest/3406), [2](https://forum.zcashcommunity.com/t/zcash-and-whonix-in-love/31197), [3](https://forum.getmonero.org/6/ideas/90786/monero-whonix-anonymous-os-caught-kissing?sort=date_desc), [4](https://lists.alpinelinux.org/~alpine/devel/%3CK-SFzX1----0%40keemail.me%3E) > I wont pay a dollar for a dead project which there are no known maintainers to it anymore. Why don't you become it's maintainer? If there was a bug bounty I'm sure someone would make some improvements. The code isn't all that mystical, it just needs someone's time. That being said it looks like [cwtch.im](https://cwtch.im) is [getting quite a few commits](https://git.openprivacy.ca/cwtch.im/cwtch/commits/master) so this might very well be a healthy fork with some new features. I hope it works out well for them. >> Considering the authors of Tox clearly state it is experimental it cannot in good faith be recommended anything more than as experimental at this point. > Well maybe you missed that as well in Ricochet main page: > ``` > Be careful > Ricochet is an experiment. > ``` > So your argument of experimental or not has no value. Yes but it's far less drastic than what Tox proposes (own crypto) vs using HiddenServices. I wish them good fortune as well and have used qTox a number of times for video conferencing. > > Additionally as I commented in https://github.com/privacytoolsIO/privacytools.io/issues/736 it has already been added to the website. Looking at your history it seems you have a problem with using the search function (many of your opened issues have been closed as DUPLICATE). > And many others wont fix , and many others still open ... so you are not making any sense at all. And if you'd actually used the search option you'd see that Tox is already on the privacytools.io website like I told you in https://github.com/privacytoolsIO/privacytools.io/issues/736#issuecomment-456901644 Anyway I've wasted enough time on you.

ghost commented

2019-01-28 09:45:03 +00:00

(Migrated from github.com)

Clearly as there's been a lack of understanding here, I suggest https://github.com/privacytoolsIO/privacytools.io/issues/746

Mikaela commented

2019-03-11 18:33:47 +00:00

(Migrated from github.com)

I tried to look into Ricochet for a moment and I think I agree with adding a warning or even removing it entirely.

No commits since August 2017 https://github.com/ricochet-im/ricochet/commits/master
Latest mailing list entry is from Mon, 16 Jul 2018 15:13:00 +0000 asking if there will be a new release and there are no responses https://lists.riseup.net/www/arc/ricochet-dev/2018-07/msg00000.html (via https://github.com/ricochet-im/ricochet/issues/388)
discussion on its future doesn't have anyone from the project commenting (or GitHub doesn't show the member flair) https://github.com/ricochet-im/ricochet/issues/425
Ricochet is said to be fingerprintable (https://github.com/ricochet-im/ricochet/issues/351#issuecomment-272749871) and as it sems to be HSv2-only (https://github.com/ricochet-im/ricochet/issues/575) I think this issue is only getting worse as I recall seeing that Tor nowadays defaults to creating version 3 hidden services unless HSv2 is specified separately.
- EDIT: Tor 0.3.5 https://blog.torproject.org/new-releases-tor-0357-03410-and-03311 and I commented there to ask about this.
ships a version of Tor that was old even in 2016? https://github.com/ricochet-im/ricochet/issues/487

Other issues getting my attention that may be interesting, but irrelevant to this issue:

There aren't reproducible builds https://github.com/ricochet-im/ricochet/issues/323
No support for multiple devices https://github.com/ricochet-im/ricochet/issues/406
Feature request for VoIP https://github.com/ricochet-im/ricochet/issues/308 (this would probably be more relevant to https://github.com/privacytoolsIO/privacytools.io/issues/746)

I tried to look into Ricochet for a moment and I think I agree with adding a warning or even removing it entirely. * No commits since August 2017 https://github.com/ricochet-im/ricochet/commits/master * Latest mailing list entry is from Mon, 16 Jul 2018 15:13:00 +0000 asking if there will be a new release and there are no responses https://lists.riseup.net/www/arc/ricochet-dev/2018-07/msg00000.html (via https://github.com/ricochet-im/ricochet/issues/388) * discussion on its future doesn't have anyone from the project commenting (or GitHub doesn't show the member flair) https://github.com/ricochet-im/ricochet/issues/425 * Ricochet is said to be fingerprintable (https://github.com/ricochet-im/ricochet/issues/351#issuecomment-272749871) and as it sems to be HSv2-only (https://github.com/ricochet-im/ricochet/issues/575) I think this issue is only getting worse as I recall seeing that Tor nowadays defaults to creating version 3 hidden services unless HSv2 is specified separately. * *EDIT: Tor 0.3.5 https://blog.torproject.org/new-releases-tor-0357-03410-and-03311 and I commented there to ask about this.* * ships a version of Tor that was old even in 2016? https://github.com/ricochet-im/ricochet/issues/487 Other issues getting my attention that may be interesting, but irrelevant to this issue: * There aren't reproducible builds https://github.com/ricochet-im/ricochet/issues/323 * No support for multiple devices https://github.com/ricochet-im/ricochet/issues/406 * Feature request for VoIP https://github.com/ricochet-im/ricochet/issues/308 (this would probably be more relevant to https://github.com/privacytoolsIO/privacytools.io/issues/746)

❤️ 2

Vincevrp commented

2019-03-11 22:43:13 +00:00

(Migrated from github.com)

I tried to look into Ricochet for a moment and I think I agree with adding a warning or even removing it entirely.

I agree on removing it @Shifterovich.

> I tried to look into Ricochet for a moment and I think I agree with adding a warning or even removing it entirely. I agree on removing it @Shifterovich.

ghost commented

2019-03-11 22:54:29 +00:00

(Migrated from github.com)

I'm too busy rn to look into it enough but there's so many good IM tools that removing the less-than-ideal ones does more good than harm. Feel free @Vincevrp

ghost commented

2019-03-11 23:09:45 +00:00

(Migrated from github.com)

I tried to look into Ricochet for a moment and I think I agree with adding a warning or even removing it entirely.

No commits since August 2017 https://github.com/ricochet-im/ricochet/commits/master

Latest mailing list entry is from Mon, 16 Jul 2018 15:13:00 +0000 asking if there will be a new release and there are no responses https://lists.riseup.net/www/arc/ricochet-dev/2018-07/msg00000.html (via ricochet-im/ricochet#388)

discussion on its future doesn't have anyone from the project commenting (or GitHub doesn't show the member flair) ricochet-im/ricochet#425

Ricochet is said to be fingerprintable (ricochet-im/ricochet#351 (comment)) and as it sems to be HSv2-only (ricochet-im/ricochet#575) I think this issue is only getting worse as I recall seeing that Tor nowadays defaults to creating version 3 hidden services unless HSv2 is specified separately.

EDIT: Tor 0.3.5 https://blog.torproject.org/new-releases-tor-0357-03410-and-03311 and I commented there to ask about this.

Yes these are the major issues here, now particularly if HSv3 is default. I can see a time sometime in the future where HSv2 may be deprecated entirely from newer Tor releases. I think at this point it's only a matter of when.

Removing it would also solve https://github.com/privacytoolsIO/privacytools.io/pull/618 meaning that would no longer be needed.

It does seem there's not going to be any new development. If you look at this ticket https://github.com/ricochet-im/ricochet/issues/574 @s-rah seems to be busy developing cwtch which is the next iteration of Ricochet.

ships a version of Tor that was old even in 2016? ricochet-im/ricochet#487

Which kind of links to the last point.

Other issues getting my attention that may be interesting, but irrelevant to this issue:

There aren't reproducible builds ricochet-im/ricochet#323

A lot of things aren't reproducible unfortunately.

No support for multiple devices ricochet-im/ricochet#406

This one would require a complete redesign, as it would no longer be peer-to-peer you'd need some sort of decentralized net or server infrastructure to store messages. It may very well be that cwtch.im is able to succeed here. Too early to be added however. Work does seem to be occurring though https://git.openprivacy.ca/cwtch.im/cwtch/commits/master

On a side note Ricochet is still included in Debian https://packages.debian.org/sid/ricochet-im but that's only because nobody has investigated it enough to find an exploit, get a CVE and then have it's unmaintained nature brought into the spotlight.

It does appear that it's not going to be added to Tails any time soon https://redmine.tails.boum.org/code/issues/8173

Feature request for VoIP ricochet-im/ricochet#308 (this would probably be more relevant to #746)

This one is kind of lol, what's the point of an anonymous messenger over Tor if your voice can be identified.

> I tried to look into Ricochet for a moment and I think I agree with adding a warning or even removing it entirely. > > * No commits since August 2017 https://github.com/ricochet-im/ricochet/commits/master > > * Latest mailing list entry is from Mon, 16 Jul 2018 15:13:00 +0000 asking if there will be a new release and there are no responses https://lists.riseup.net/www/arc/ricochet-dev/2018-07/msg00000.html (via [ricochet-im/ricochet#388](https://github.com/ricochet-im/ricochet/issues/388)) > > * discussion on its future doesn't have anyone from the project commenting (or GitHub doesn't show the member flair) [ricochet-im/ricochet#425](https://github.com/ricochet-im/ricochet/issues/425) > > * Ricochet is said to be fingerprintable ([ricochet-im/ricochet#351 (comment)](https://github.com/ricochet-im/ricochet/issues/351#issuecomment-272749871)) and as it sems to be HSv2-only ([ricochet-im/ricochet#575](https://github.com/ricochet-im/ricochet/issues/575)) I think this issue is only getting worse as I recall seeing that Tor nowadays defaults to creating version 3 hidden services unless HSv2 is specified separately. > - _EDIT: Tor 0.3.5 https://blog.torproject.org/new-releases-tor-0357-03410-and-03311 and I commented there to ask about this._ Yes these are the major issues here, now particularly if HSv3 is default. I can see a time sometime in the future where HSv2 may be deprecated entirely from newer Tor releases. I think at this point it's only a matter of when. Removing it would also solve https://github.com/privacytoolsIO/privacytools.io/pull/618 meaning that would no longer be needed. It does seem there's not going to be any **new** development. If you look at this ticket https://github.com/ricochet-im/ricochet/issues/574 @s-rah seems to be busy developing cwtch which is the next iteration of Ricochet. > * ships a version of Tor that was old even in 2016? [ricochet-im/ricochet#487](https://github.com/ricochet-im/ricochet/issues/487) Which kind of links to the last point. > > Other issues getting my attention that may be interesting, but irrelevant to this issue: > > There aren't reproducible builds [ricochet-im/ricochet#323](https://github.com/ricochet-im/ricochet/issues/323) > A lot of things aren't reproducible unfortunately. > * No support for multiple devices [ricochet-im/ricochet#406](https://github.com/ricochet-im/ricochet/issues/406) > This one would require a complete redesign, as it would no longer be peer-to-peer you'd need some sort of decentralized net or server infrastructure to store messages. It may very well be that [cwtch.im](https://cwtch.im/) is able to succeed here. Too early to be added however. Work does seem to be occurring though https://git.openprivacy.ca/cwtch.im/cwtch/commits/master On a side note Ricochet is still included in Debian https://packages.debian.org/sid/ricochet-im but that's only because nobody has investigated it enough to find an exploit, get a CVE and then have it's unmaintained nature brought into the spotlight. It does appear that it's not going to be added to Tails any time soon https://redmine.tails.boum.org/code/issues/8173 > * Feature request for VoIP [ricochet-im/ricochet#308](https://github.com/ricochet-im/ricochet/issues/308) (this would probably be more relevant to #746) This one is kind of lol, what's the point of an anonymous messenger over Tor if your voice can be identified.

ghost commented

2019-03-12 17:27:31 +00:00

(Migrated from github.com)

I see the argument for removing it and agree with most points, however it is sad to see it unmaintained and removed since it is currently one of the only decent (in design) Tor-default, p2p chat applications.

I say we put it in worth mentioning with the warning to update the tor binary. However i think i'm a little outnumbered, so i'll just remove it if no one else makes a pr soon.

I see the argument for removing it and agree with most points, however it is sad to see it unmaintained and removed since it is currently one of the only decent (in design) Tor-default, p2p chat applications. I say we put it in worth mentioning with the warning to update the tor binary. However i think i'm a little outnumbered, so i'll just remove it if no one else makes a pr soon.

ghost commented

2019-03-13 10:01:42 +00:00

(Migrated from github.com)

(in design) Tor-default, p2p chat applications.
I say we put it in worth mentioning with the warning to update the tor binary. However i think i'm a little outnumbered, so i'll just remove it if no one else makes a pr soon.

I do like the way that Ricochet works. Nothing really quite comes close to it in regard to metadata resistance.

I think it's a less of a case of it being unmaintained, and more of a case of the current maintainers are active on the successor project, cwtch which aims to "fix" some of the issues with Ricochet (which was basically TorChat with a nicer UI). One of those things being updating the Tor binary, multi device support and offline messaging. Unfortunately it is still very 'alpha' at this state. Using something that is that experimental may very well be detrimental.

I do think we need to reorganize the instant messenger section. How we do that is a topic of discussion. https://github.com/privacytoolsIO/privacytools.io/issues/746 https://github.com/privacytoolsIO/privacytools.io/issues/729 because all things simply are not equal.

> (in design) Tor-default, p2p chat applications. > I say we put it in worth mentioning with the warning to update the tor binary. However i think i'm a little outnumbered, so i'll just remove it if no one else makes a pr soon. I do like the way that Ricochet works. Nothing really quite comes close to it in regard to metadata resistance. I think it's a less of a case of it being unmaintained, and more of a case of the current maintainers are active on the successor project, [cwtch](https://cwtch.im) which aims to "fix" some of the issues with Ricochet (which was basically TorChat with a nicer UI). One of those things being [updating the Tor binary](https://git.openprivacy.ca/cwtch.im/cwtch/issues/155), [multi device support](https://git.openprivacy.ca/cwtch.im/cwtch/issues/58) and offline messaging. Unfortunately it is still very 'alpha' at this state. Using something that is that experimental may very well be detrimental. I do think we need to reorganize the instant messenger section. How we do that is a topic of discussion. https://github.com/privacytoolsIO/privacytools.io/issues/746 https://github.com/privacytoolsIO/privacytools.io/issues/729 because all things simply are not equal.

👍 1

E3V3A commented

2019-03-15 21:38:20 +00:00

(Migrated from github.com)

I really suggest all of you to read THIS POST regarding Ricochet by @s-rah.

➡️ Cwtch.

and hosted at:

I really suggest all of you to read [THIS POST](https://github.com/ricochet-im/ricochet/issues/578#issuecomment-393049811) regarding Ricochet by @s-rah. ## :arrow_right: [Cwtch](https://openprivacy.ca/blog/2019/02/14/cwtch-alpha/). and hosted at: * https://cwtch.im/ * https://git.openprivacy.ca/cwtch.im/cwtch

ghost commented

2019-03-16 01:35:57 +00:00

(Migrated from github.com)

As for this project, there is clearly some maintenance to be done to prevent longer-term rot. Standard ricochet packagings e.g. debian should , AFAICR, prefer system installed/newer Tor versions. In my opinion, there is no reason in the short term and in many cases to consider Ricochet unsafe to use,but it is experimental and volunteer driven.

This is the most relevant part IMO. Good reason to keep/put it in worth mentioning

>As for this project, there is clearly some maintenance to be done to prevent longer-term rot. Standard ricochet packagings e.g. debian should , AFAICR, prefer system installed/newer Tor versions. In my opinion, there is no reason in the short term and in many cases to consider Ricochet unsafe to use,but it is experimental and volunteer driven. This is the most relevant part IMO. Good reason to keep/put it in worth mentioning

Mikaela commented

2019-03-16 11:44:27 +00:00

(Migrated from github.com)

Is having up-to-date Tor enough if the software itself doesn't support hidden service version 3? Has anyone tested that it still works with Tor versions that default to HSv3 (or it uses HSv2 explicitly and isn't affected by the default changing)?

If the answer is yes to both, then I think it would be OK to keep as worth mentioning on Debian, but will most of Windows users start updating the Tor binary? (More relevant question might be whether they would install Ricochet at all though.)

Is having up-to-date Tor enough if the software itself doesn't support hidden service version 3? Has anyone tested that it still works with Tor versions that default to HSv3 (or it uses HSv2 explicitly and isn't affected by the default changing)? If the answer is yes to both, then I think it would be OK to keep as worth mentioning on Debian, but will most of Windows users start updating the Tor binary? (More relevant question might be whether they would install Ricochet at all though.)

Mikaela commented

2019-03-16 11:53:22 +00:00

(Migrated from github.com)

I opened an issue to ask if Ricochet should instead be replaced by Cwtch (https://github.com/privacytoolsIO/privacytools.io/issues/781).

👍 1

ghost commented

2019-03-17 08:34:21 +00:00

(Migrated from github.com)

I really suggest all of you to read THIS POST regarding Ricochet by @s-rah.

Ah yes, that more a less repeats what was said in https://github.com/ricochet-im/ricochet/issues/574#issuecomment-385548780 that I linked in my comment https://github.com/privacytoolsIO/privacytools.io/issues/474#issuecomment-471776595

Is having up-to-date Tor enough if the software itself doesn't support hidden service version 3? Has anyone tested that it still works with Tor versions that default to HSv3 (or it uses HSv2 explicitly and isn't affected by the default changing)?

I decided to test this between two hosts. Host 1 from the Debian repositories and Host 2 a Windows machine. Here's what I started with:

[
  {
    "Machine": "1",
    "OS": "Debian 9",
    "Versions": {
      "Ricochet": "1.1.4",
      "Tor": "0.2.9.16 (git-9ef571339967c1e5)",
      "Libevent": "2.0.21-stable",
      "OpenSSL": "1.1.0j",
      "Zlib": "1.2.8"
    }
  },
  {
    "Machine": "2",
    "OS": "Windows 10",
    "Versions": {
      "Ricochet": "1.1.4",
      "Tor": "0.2.8.9",
      "Libevent": "2.0.22-stable",
      "OpenSSL": "1.0.2j",
      "Zlib": "1.2.8"
    }
  }
]

Everything seemed to work. However Host 2 is vulnerable as it is using the shipped copy of Tor. Note to see the version number one needs to add Log notice file C:\Users\user\Desktop\tor.log to your torrc to enable logging.

Now updating the Windows version using the binaries from torbrowser-install-win64-8.0.6_en-US.exe

18,21c18,21
<       "Tor": "0.2.8.9",
<       "Libevent": "2.0.22-stable",
<       "OpenSSL": "1.0.2j",
<       "Zlib": "1.2.8"
---
>       "Tor": "0.3.5.7 (git-9beb085c10562a25)",
>       "Libevent": "2.1.8-stable",
>       "OpenSSL": "1.0.2q",
>       "Zlib": "1.2.11"

Things were not so great. The first error I got was

The code execution cannot proceed because zlib1.dll was not found. Reinstalling the program may fix the problem.

The code execution cannot proceed because libevent-2-1.6.dll was not found. Reinstalling the program may fix the problem.

So I copied the binaries zlib1.dll, libevent-2-1-6.dll, libevent_core-2-1-6.dll, libevent_extra-2-1-6.dll also into Ricochet directory ie C:\Users\user\AppData\Local\Ricochet.

Unfortunately then I got:

The application was unable to start correctly (0xc000007b). Click OK to close the application.

So it seems its not as simple as it was back then https://github.com/privacytoolsIO/privacytools.io/pull/618 to just update tor.exe.

If the answer is yes to both, then I think it would be OK to keep as worth mentioning on Debian, but will most of Windows users start updating the Tor binary? (More relevant question might be whether they would install Ricochet at all though.)

Well I guess that depends on whether we can solve the above issue.

> I really suggest all of you to read [THIS POST](https://github.com/ricochet-im/ricochet/issues/578#issuecomment-393049811) regarding Ricochet by @s-rah. Ah yes, that more a less repeats what was said in https://github.com/ricochet-im/ricochet/issues/574#issuecomment-385548780 that I linked in my comment https://github.com/privacytoolsIO/privacytools.io/issues/474#issuecomment-471776595 > Is having up-to-date Tor enough if the software itself doesn't support hidden service version 3? Has anyone tested that it still works with Tor versions that default to HSv3 (or it uses HSv2 explicitly and isn't affected by the default changing)? I decided to test this between two hosts. Host 1 from the Debian repositories and Host 2 a Windows machine. Here's what I started with: ```json [ { "Machine": "1", "OS": "Debian 9", "Versions": { "Ricochet": "1.1.4", "Tor": "0.2.9.16 (git-9ef571339967c1e5)", "Libevent": "2.0.21-stable", "OpenSSL": "1.1.0j", "Zlib": "1.2.8" } }, { "Machine": "2", "OS": "Windows 10", "Versions": { "Ricochet": "1.1.4", "Tor": "0.2.8.9", "Libevent": "2.0.22-stable", "OpenSSL": "1.0.2j", "Zlib": "1.2.8" } } ] ``` Everything seemed to work. However Host 2 is vulnerable as it is using the shipped copy of Tor. Note to see the version number one needs to add `Log notice file C:\Users\user\Desktop\tor.log` to your torrc to [enable logging](https://www.torproject.org/docs/tor-manual.html.en). Now updating the Windows version using the binaries from `torbrowser-install-win64-8.0.6_en-US.exe` ```diff 18,21c18,21 < "Tor": "0.2.8.9", < "Libevent": "2.0.22-stable", < "OpenSSL": "1.0.2j", < "Zlib": "1.2.8" --- > "Tor": "0.3.5.7 (git-9beb085c10562a25)", > "Libevent": "2.1.8-stable", > "OpenSSL": "1.0.2q", > "Zlib": "1.2.11" ``` Things were not so great. The first error I got was > The code execution cannot proceed because `zlib1.dll` was not found. Reinstalling the program may fix the problem. > The code execution cannot proceed because `libevent-2-1.6.dll` was not found. Reinstalling the program may fix the problem. So I copied the binaries `zlib1.dll`, `libevent-2-1-6.dll`, `libevent_core-2-1-6.dll`, `libevent_extra-2-1-6.dll` also into Ricochet directory ie `C:\Users\user\AppData\Local\Ricochet`. Unfortunately then I got: > The application was unable to start correctly (0xc000007b). Click OK to close the application. So it seems its not as simple as it was back then https://github.com/privacytoolsIO/privacytools.io/pull/618 to just update `tor.exe`. > If the answer is yes to both, then I think it would be OK to keep as worth mentioning on Debian, but will most of Windows users start updating the Tor binary? (More relevant question might be whether they would install Ricochet at all though.) Well I guess that depends on whether we can solve the above issue.

blacklight447 commented

2019-08-09 20:53:19 +00:00

(Migrated from github.com)

as ricochet has been demoted to worth mentioning and now also has several warnings, i think it is right to close this issue

odiferousmint commented

2019-09-30 13:58:13 +00:00

(Migrated from github.com)

I second that we should add a notice regarding using a new version of Tor. I think the only publicly known vulns in the main ricochet client right now are just in the Tor version it uses.

See below.

Is having up-to-date Tor enough if the software itself doesn't support hidden service version 3? Has anyone tested that it still works with Tor versions that default to HSv3 (or it uses HSv2 explicitly and isn't affected by the default changing)?

No, it is not enough, because Ricochet uses RSA1024[1] instead of ED25519-V3[2] as KeyType.

[1] https://github.com/ricochet-im/ricochet/blob/master/src/tor/AddOnionCommand.cpp#L56
[2] https://github.com/torproject/torspec/blob/master/control-spec.txt#L1608

> I second that we should add a notice regarding using a new version of Tor. I think the only publicly known vulns in the main ricochet client right now are just in the Tor version it uses. See below. > Is having up-to-date Tor enough if the software itself doesn't support hidden service version 3? Has anyone tested that it still works with Tor versions that default to HSv3 (or it uses HSv2 explicitly and isn't affected by the default changing)? No, it is not enough, because Ricochet uses `RSA1024`[1] instead of `ED25519-V3`[2] as `KeyType`. [1] https://github.com/ricochet-im/ricochet/blob/master/src/tor/AddOnionCommand.cpp#L56 [2] https://github.com/torproject/torspec/blob/master/control-spec.txt#L1608

This repo is archived. You cannot comment on issues.