Remove Ricochet from Whonix

[iry]

Qubes-Whonix 14.0.0.6.9 TemplateVMs for R3.2 and R4--Testers Wanted!

Remove the Dead project Ricochet = 2 years no voice

I can help remove it from Whonix but first let’s seek for more input on this issue. Could you please share your opinions on this?

Related discussion:

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

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

The project seems to be inactive for a while now:
https://github.com/ricochet-im/ricochet/graphs/contributors

---

We may still make it into Whonix 14, but remove it later from Whonix 15+. Therefore, we will have more time focusing on the release of Whonix 14.

[TNT_BOM_BOM]

I can help remove it from Whonix but first let’s seek for more input on this issue. Could you please share your opinions on this?

• the first link referring to another project called Briar and its laterally sucks why?

1- it supporting only android which Ricochet itself wasnt made for any phone platform.
2- it doesnt even mention where did they do any progress to Ricochet
3- not inside Debian package nor i think will be in the soon time

• second link is not much helping as the first link (and S-rah has no idea what does it mean its not maintained anymore)

so these my opinions , in Conclusion Ricochet is BAD to be installed by default inside whonix.

there r alot of cool apps built on matrix going to come by debian packages on buster. so i think waiting to that time is the only way to go for now atm.

We may still make it into Whonix 14, but remove it later from Whonix 15+. Therefore, we will have more time focusing on the release of Whonix 14.

yeah sure , just hope u dont forget that.

[Patrick]

This is rabbit hole.

[1] Whonix is based on Debian. It depends on Debian. Whonix depends on hundredths of packages which themselves depend on thousands of other packages (tools) and libraries.

If you believe ricochet is dead, therefore insecure and should be removed, then this is primarily a bug to be reported to Debian.

Definition of dead?

• code base untouched for >2 years?
• no word from author for >2 years?

This first needs a very clear definition. Otherwise we won’t have any other subject ever again arguing what is dead what is not.

I am sure, under that definition there are a ton of packages from [1] which meet that definition.

[TNT_BOM_BOM]

If you believe ricochet is dead, therefore insecure and should be removed, then this is primarily a bug to be reported to Debian.

That debian should take care of it.

but Debian philosophy through this subject it cant be ours why?

because our distro is anonymity focused not compatibility problems (only). so giving this time to the app and just trusting Debian pointview on its components that doesnt mean our product is safe. anonymity needs active projects and fix and upgrades the issues with nonstop (even if its taking long time in the fixation process). but being zero active project with no improvements to any tickets = run away for ur life if u r searching for anonymity.

so maybe the app still working on debian and compatible with its distros versions but that doesnt mean its safe and good decision to keep using it.

[BubonicChronicWhonix]

Does the version of Ricochet bundled with Debian/Whonix have any known vulnerabilities?

[HulaHoop]

I know of s-rah’s efforts on building a secure remote command shell using Ricochet and apparently they are on-going. I believe that besides Patrick’s definition we should also not remove a package if:

• it has no known sec vulns
• does not require major maintenance efforts on our part or is a core dependency.

tl;dr I’m for keeping it at the moment and monitoring how things play out.

[Patrick]

Bubonic Chronic:

Does the version of Ricochet bundled with Debian/Whonix have any known vulnerabilities?

None reported against Debian.

[BubonicChronicWhonix]

I see no reason to remove it then. Worth keeping an eye on maybe. But no need to remove it if it works.

[TNT_BOM_BOM]

it has no known sec vulns

• its true there is non yet. but what if one security existed while we have our version of whonix 14 stable ? or 15 …?

the flaw will effect all whonix users. Without the ability even to remove/purge it because of this problem:

Continuing the discussion from Whonix VirtualBox 14.0.0.5.5 Testers Wanted!:

Whonix VirtualBox 14.0.0.5.5 Testers Wanted!

No way to solve. Debian isuse. Debian dpkg lacks “weak dependencies” feature.

https://www.whonix.org/wiki/Whonix_Debian_Packages

and since its not maintained atm then no way also to wait for a patch. the only waiting is for the next release of whonix without ricochet.

does not require major maintenance efforts on our part or is a core dependency.

• actually Ricochet has a problem of running inside whonix (i couldnt make it work) check:

Continuing the discussion from Whonix VirtualBox 14.0.0.5.5 Testers Wanted!:

Whonix VirtualBox 14.0.0.5.5 Testers Wanted!

Ricochet (as well as onionshare / ZeroNet) unfortunately needs some manual steps by the user before these work.

• the problem of which i think no body studied the effect of it, Ricochet considering each client as hidden service but Ricochet last support is to Tor version 0.2.5 and by default now whonix support 0.3.x. so im not sure on which version of onioning its going to create, is it the v2 or v3 ? also there r many fixes to Tor for hidden services from v0.2.x to 0.3.x.

in conclusion, Ricochet is great app with Tor but its only were continued …

i suggest to check Matrix there is too many users migrating to it. (as also Tox chat no more supporting Debian…)

[HulaHoop]

its true there is non yet. but what if one security existed while we have our version of whonix 14 stable ? or 15 …?

the flaw will effect all whonix users. Without the ability even to remove/purge it because of this problem:

The problem with this 0day argument its fatalistic and there is no way to verify it. There is are always 0days in the kernel too but that doesn’t mean we should abandon all hope and stop developing?

Understand ricochet is also written in memory safe python (though migrating to Go) and written with security in mind. There are many other base Debian packages that are not. If there is something that’s a weaker link its probably something else.

Worst case scenario it won’t affect anyone who doesn’t run it and so I wouldn’t consider it affecting “all Whonix users”

i suggest to check Matrix there is too many users migrating to it. (as also Tox chat no more supporting Debian…)

Matrix is interesting but can you suggest a desktop client already packaged for Debian?

[HulaHoop]

I will split the topic into another thread about Matrix clients to discuss it.

Matrix clients on Debian

There is UI for stretch which is Weechat There are 2 GUI applications for Buster ** Nheko ** Quaternion

[Patrick]

and since its not maintained atm then no way also to wait for a patch. the only waiting is for the next release of whonix without ricochet.

This is wrong.

Example: thunderbird / torbirdy / enigmail was recently removed without Whonix 14 -> 15 release upgrade. (Thunderbird / enigmail no longer installed / sudo apt-get dist-upgrade - The following packages will be REMOVED: enigmail)

Whonix VirtualBox 14.0.0.5.5 Testers Wanted!

No way to solve. Debian isuse. Debian dpkg lacks “weak dependencies” feature.

https://www.whonix.org/wiki/Whonix_Debian_Packages

Doesn’t apply here.

Whonix VirtualBox 14.0.0.5.5 Testers Wanted! is about VLC on Whonix-Gateway due to a weird and hard to remove because no Whonix package on Whonix-Gateway directly wants to install VLC. Ticket: https://phabricator.whonix.org/T786

Directly meaning “look into https://github.com/Whonix/anon-meta-packages/blob/master/debian/control”. Only package whonix-workstation-default-applications-gui Depends: vlc and whonix-workstation-default-applications-gui is not installed on Whonix-Gateway. So VLC on Whonix-Gateway is a dependency of something else.

Removing ricochet without release upgrade would be easy since package Whonix-Workstation directly Depends: on ricochet-im Directly meaning “look into https://github.com/Whonix/anon-meta-packages/blob/master/debian/control” where you can see whonix-workstation-default-applications-gui Depends: ricochet-im.

[Patrick]

but what if one security existed while we have our version of whonix 14 stable ? or 15 …?

Debian security team would patch it independently if upstream is dead or not.

[TNT_BOM_BOM]

consider alternative with active development from debian repos:

http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/t/tox-over-tor-and-i2p-in-development/1219/11

[HulaHoop]

Ricochet is working well here. There is absolutely no need to remove a functional and stable piece of software after all the effort it took to support and integrate in Whonix.

[Patrick]

Removed since no longer working in Whonix 15 despite all efforts.

ricochet support

Good find. Then there is nothing we can do to fix it in this situation. I nominate it for removal in the next point release (though keep the onion-grater profie around becuase it isn’t visible or takes up space) as keeping broken software will give a bad impression of the distro. cwtch is promising as a successor but I won’t hold my breath over a Debian package. She releases Docker containers though which are difficult to integrate because you can’t really update them as securely as packages.

[Patrick]

@Patrick

Removed since no longer working in Whonix 15 despite all efforts.

ricochet support

This has been figured out and fixed thanks to @JeremyRand! So once that is merged and there’s a new ricochet release, ricochet might be again functional inside Whonix. This also opens the door for considering to re-install ricochet by default inside Whonix if/when ricochet hits the next Debian stable.