Please @special do something
cypherbits opened this issue Β· 54 comments
Yeah, ricochet really needs an update and you could make it so much better
-Recompiling with Qt 5.12 LTS.
-Master branch, no need to review pull requests.
-Update Tor to latest 0.3.x series.
I already did it locally, but I don't own this official repository.
would it be possible for you to fork Ricochet and update it like you did so others could download it?
would it be possible for you to fork Ricochet and update it like you did so others could download it?
OK, I will, check my fork in a few days.
Adding v3 onions will be hard for me (not a C developer) but not impossible.
People willing to help me develop and fix Ricochet do it on my fork:
Help me test this build on Linux:
https://github.com/cypherbits/ricochet/releases/tag/v1.1.4.1
@cypherbits any chance of getting a windows build?? I saw you released a version on your fork
My richochet ID ricochet:vzhpjiibxba3eycb
@mva1985 after days of trying to compile it to Windows I think I almost have it.
There was a bug which is not fixed on main Ubuntu yet that made an error compiling Qt for Windows...
I will make a Wiki entry on how I did it and I hopefully will publish the Windows port soon.
Not good, I'm still stuck trying to cross compile for Windows, not with compile errors on the OpenSSL front. I even tried to compile it on Windows with a bunch of errors too.
We need developers. I'm not a C developer.
I'm sorry for the problems you're having but I appreciate your efforts
Sorry to say I don't have much time right now to work on this and that I finally could not compile it.
There are many developers out there, why no one wanna help me a little? :(
With some tweaks, I could cross-build ricochet for Windows on the current Debian sid with mingw64.
Could anybody tell me how to update git submodules under buildscripts/src/ (such as Tor)? I tried, but it's too confusing for me...
they only way I could help is by testing a windows build if you are successful
Hey @mhatta: I haven't tested this myself, but the command git submodule update --remote
should work (in the root of buildscripts
). If you need to change the URLs for some reason, they're stored in buildscripts/.gitmodule
.
I'd just like to take a moment to note that an organisation I'm working with at the moment is gathering resources to bring Ricochet up to speed: see https://github.com/blueprint-freespeech/ricochet-refresh for more.
With some tweaks, I could cross-build ricochet for Windows on the current Debian sid with mingw64.
Could anybody tell me how to update git submodules under buildscripts/src/ (such as Tor)? I tried, but it's too confusing for me...
I tried to update submodules, Qt version too, but it broke... it is not detecting correct submodules or something... IDK
There are some modules that do not exists in newer versions of Qt because they are integrated on main Qt.
PD: happy to see people contributing.
PD2: Please people, post how and where do you compile things.
So I've got a successful build with current Tor on Ubuntu 18.04 with the Linux buildscripts -- I'll look at Windows cross-building soon.
Seems I could produce Windows 64bit installer package w/ Qt 5.12.4 & Tor 0.3.5.8. Try it if you want:
https://github.com/mhatta/ricochet/releases/download/test/Ricochet.exe
I'll refine this later.
Hi @noneuclideangirl, currently I'm working on my own fork repos, but if you could add me, we can work together on blueprint-freespeech repos. How do you think?
Me too, I want to contribute, I know about QML/design part and can help compiling things.
@mhatta please, explain more how did you compile it for WIndows. Where and how.
Feel free to -- I don't have the ability to add you to the team but you're more than welcome to submit work!
@noneuclideangirl Well, then It doesn't make much sense to use your repo, so I'll stick to mine...
@cypherbits You may check my buildscripts repo: https://github.com/mhatta/buildscripts/
My Ricochet ID is (for now) ricochet:tn5bmeldy2w6ghgf , but most of the time I'm offline.
Building with mingw32 is really difficult and I couldn't succeed after all. Somehow 32bit/64bit confusion happens and the generated binary never works. Building with mingw64 is quite easy but there are still several pitfalls (posix / w32 incompatibility, localtime_r problem, etc.). Needs more work.
I think @s-rah 's cwtch is very promising. I'm willing to housekeep ricochet, but maybe new effort should go into cwtch. The problem is, I know C++, but I'm a Go illiterate...
Ok, I think this one is good enough: https://github.com/mhatta/ricochet/releases/tag/v1.4.1-revised1
I'm now consolidating the existing patches.
If everyone of us create our own repository and we don't have one main official repository, we will accomplish nothing.
Important: planning.
I think as we are just a few, we should want to maintain Ricochet, update Qt, some QML and Tor versions and include some fixes and GUI fixes/design.
We can even try to include onion v3 support, that would be good, but, please, do not try to get any new big features, we are few people and there is an alternative to Ricochet already functional called Cwtch.im
That means we should maintain Ricochet + get fixes + get v3 onions = stable and SECURE Ricochet (as there won't be any new code to be vulnerable).
Cwtch is written in Golang so is memory safe by default, and includes hidden and zero-knowenledge servers to store messages when users are offline and more features coming soon. We should join that project and maintain Ricochet only until a good stable version of Cwtch is released.
I know this sounds really ugly but what about rewriting in nodeJS with a web front end? I'm not a fan of this myself but I have to admit, system compatibility is very good.
Also my id is ricochet:ricochetytijv2kh
if someone is interested. (Yes, it has ricochet twice)
I know this sounds really ugly but what about rewriting in nodeJS with a web front end? I'm not a fan of this myself but I have to admit, system compatibility is very good.
Also my id is
ricochet:ricochetytijv2kh
if someone is interested. (Yes, it has ricochet twice)
Nope nope nope nope nope
A really bad idea. nodeJS is not that safe and consumes many system resources.
As I said, the new project Cwtch is already making new features Richochet does not have. It is implemented in Goland: memory safe but fast and cheap for systems.
Ricochet: maintenance mode.
New features and development: Cwtch.
Do not start your own project, we want a good solution for users. I started TorTribe (you can see my Github) in Java, but I will close it and join Cwtch so together we can make Cwtch great for all people.
nodeJS is not that safe and consumes many system resources.
There are AFAIK no safety problems in the node engine itself. In fact, a JS implementation is probably safer then the original ricochet client considering JS doesn't suffers from attacks that target unmanaged languages.
The claim about it eating a lot of system resources is also a lie. In fact, my nodeJS test server application eats about 10 MB of memory, while ricochet uses over 40 when idling for a few hours.
Do not start your own project, we want a good solution for users.
That's one of the worst advice you can give to people. From a security point of view, software diversification is very important. Any security flaw found would be devastating if all people were to use the same program. An added benefit is that when someone wants to fork and make changes to a client, they can pick the language they understand best.
nodeJS is not that safe and consumes many system resources.
There are AFAIK no safety problems in the node engine itself. In fact, a JS implementation is probably safer then the original ricochet client considering JS doesn't suffers from attacks that target unmanaged languages.
The claim about it eating a lot of system resources is also a lie. In fact, my nodeJS test server application eats about 10 MB of memory, while ricochet uses over 40 when idling for a few hours.
Do not start your own project, we want a good solution for users.
That's one of the worst advice you can give to people. From a security point of view, software diversification is very important. Any security flaw found would be devastating if all people were to use the same program. An added benefit is that when someone wants to fork and make changes to a client, they can pick the language they understand best.
What I mean about that is that there is no benefit of redoing Ricochet with nodejs and we should focus on helping other project replacing Ricochet already in development.
NodeJS on the GUI part is RAM hungry and the app executable is big too.
We CAN and SHOULD recompile Ricochet with the newest Qt and change some QML so the memory footprint is lower. Actually just updating Qt version should do the magic as QML engine improved a lot.
I am not saying not to do software diversification, but sometimes each people start doing the same thing in parallel from the start and they stop and get tired and accomplished just an unusable thing. If the efforts were together, they would have developed a good solution.
I mean there is a tiny line between diversity and fragmentation. If we start forking Ricochet and developing on our own, which version should end users download?
@mhatta I ran your installer and when I started ricochet it gave me an error that libstdc++-6.dll was missing
I agree that forking too hard is not a great idea. Blueprint has some (small at present) resources, and we currently have a developer working on getting updated releases ready. We can add you as contributors if you like β our goal is to bring Ricochet up to speed so that those who use it have a more secure solution than the current old version.
We also have a few ideas on how to further improve Ricochet (a better regex engine, ECDH key agreement etc.) While Cwtch is a promising option, it doesn't have the maturity, userbase, and developer community that Ricochet has. We want to harness that to make a more secure solution widely accessible.
Just want to mention that I am working on an alternative that also will support android and ios (if Apple allows it in their store).
https://github.com/jgaa/darkspeak
The good news on that front @jgaa is that Qt supports Android now, so we could absolutely look at porting Ricochet over.
@noneuclideangirl is that developer working on public github?
Has Blueprint access to the original Ricochet Github repository?
@jgaa that is what I meant by fragmentation: every one of us starting a side project with the same goals... You are developing DarkSpeak with QtQML, I am was TorTribe in Java... and it's the same, actually mine was a bit different.
We should make just one project. Even Retroshare project is out there already using Tor and I2P...
@mhatta I ran your installer and when I started ricochet it gave me an error that libstdc++-6.dll was missing
Could you try this one? I tested it in a clean Win10 dev environment on Hyper-V, seems it works.
@mhatta I ran your installer and when I started ricochet it gave me an error that libstdc++-6.dll was missing
Could you try this one? I tested it in a clean Win10 dev environment on Hyper-V, seems it works.
i'll give it a shot.... thank you
I think it's nice to list all known secure instant messaging software. Here's my take:
Now I can build Ricochet with the latest Qt 5.13.0. With several easy fixes, I released the unofficial 1.1.4.1.
@cypherbits so what we're working on is getting releases with updated dependencies ready -- we're working on the build scripts fork https://github.com/blueprint-freespeech/refresh-buildscripts. Planning to have binaries released on our website soon.
@cypherbits I think it's good to have a variety of projects. My aim is to make something that work on desktop and mobile, that supports group chats, multiple active devices (like jabber and sip - you can be logged in on your laptop and your phone to the same account) and also in the future some social features like tweets and blogs - load balanced by distributing the content to clients that are configured to work as hubs. I also wanted added security, so that applications that can listen to the localhost interface (like antivirus programs and malware) cannot capture conversations or meta-data.
The nice thing with a variety of projects is that one get to use ones inspiration and try out things. It would be nice though to have a very simple protocol that with some basic features that everyone could implement so that users could use their favorite client - but talk with anyone else.
@noneuclideangirl @mhatta @cypherbits @jgaa: Can you join forces for have new versions and not several forks?
@special @s-rah: Alive? It is possible to add people in @ricochet-im team?
Since I've been approached a few times about this now, I will make it clear where I stand. Years ago will working on the security of ricochet I started working on go library (goricochet which then became libricochet-go), the original plan was to transition the underlying C++ codebase to a go library (which is why there are go libraries under ricochet-im). While that was going on, I started a new project Cwtch - which was originally meant to be an exploration in adding group messaging to Ricochet.
However, focus and funding take hold and, while I can't speak for special, my focus was diverted to Open Privacy (https://openprivacy.ca) and as Cwtch developed it became clear that given all the issues we knew about and all the new features we wanted to add, a rewrite -and a new ui- was necessary.
- Open Privacy has put in a lot of effort to extending the protocol in Cwtch (https://openprivacy.ca/blog/2019/02/14/cwtch-alpha/) which is based on the ricochet protocol, but now also supports:
- group chat
- additional non-chat applications (lists / discussion)
- android support
- v3 onion support (now exclusive)
- more flexible tor control handling
- a much improved authentication protocol (3DH over the RSA Challenge/Proof - offering both better deniability properties and protocol-level encryption) (now exclusive)
You can check out our latest alpha release (https://git.openprivacy.ca/cwtch.im/ui/releases)
I'm honestly not sure it makes sense to turn back the clock and try to backport all those improvements into an application written in a non-memory safe language, in 2019. Cwtch is already in compatible with older ricochet clients because we couldn't justify keeping v2 onion support - it's too slow and there are much better alternatives now that can be seamlessly adapted into other modern privacy protocols.
- Open Privacy is focused now researching applications that can improve scalability of metadata-resistant group chats, improved mobile use, better UX etc. The original ricochet codebase was not written to be a library, and as such it is way more tricky to extend and use as the base for other applications. This was the main reason I wrote a go-based ricochet library many years ago, and the main reason we decided to build a new UI from scratch.
The reason I am reluctant to add anyone to the github team is because I know the issues that lurk in the codebase, and the amount of work required to fix them - rolling out a new legacy ricochet release with a new tor version won't fix those problems - a new release without those gives users a false sense of security.
If there truly is desire to revive the old ricochet, I would strongly encourage you to redo both the authentication protocol and the regex handling - both are currently a source of legacy issues, and known vulnerabilities - neither are trivial to fix but If there are secure PRs for those submitted I will try and find time to review & merge them.
If there really is willingness and effort to fund work /input energy into metadata resistant communications, I would ask you to deeply consider joining us to move Cwtch forward rather than investing effort into reviving the original Ricochet.
Many thanks for answering. I see now there is actually some "vulnerabilities" on the protocol and we should focus on Cwtch. Now, I think a little recompile and updated Tor won't hurt because many people is still using it and Cwtch is on alpha stage.
The future is Cwtch, but the present is still Ricochet as many people is using it ... I think people with access like @s-rah should make an official redirect to Cwtch from Ricochet websites when Cwtch is considered Beta or Stable.
@s-rah Thanks a lot for sharing your thought!
As I said, I think Cwtch is very promising and personally consider contributing to it. I also think you (or more likely @special) should have sunsetted Ricochet gracefully as the Tor Project did for their Tor Messenger.
I also like the almost tin-can-phonesque simplicity of Ricochet. In addition, bugs you mentioned might be important but not showstoppers or non-fixable I believe. So I'm willing to housekeep Ricochet for a while in my forked repo.
I'm also willing to work with @noneuclideangirl or Blueprint folks, but I'm not sure how much effort they are willing to put. As far as I see, they are only updating README, LICENSE or such...
@mhatta we have some developers actively working on an updated release at the moment -- see repositories https://github.com/blueprint-freespeech/ricochet-refresh and https://github.com/blueprint-freespeech/refresh-buildscripts.
I'd also like to thank @s-rah for her contributions and issues raised, as well as @special for his help in private correspondence. I think Cwtch is super promising and I'd love to contribute when I have more time and resources personally. I'm currently doing contracted work for Blueprint, and our goal at the moment is to "fill the gap" and provide a safer version for current active users of Ricochet. Hope that clears things up!
@noneuclideangirl Yeah I saw your repos. There seem to be several committers now. Could you give me committer privilege?
@mhatta I don't have the authority to do that within the organisation, but if you're interested in contributing on a regular basis shoot Suelette an email at suelette@blueprintforfreespeech!
Blueprint is putting out a pre-release of Ricochet Refreshed for MacOS that incorporates the latest version of Tor. Thereβs more detail here: ricochetrefresh.net. This is our first step toward making Ricochet safer. Itβs a pre-release so expect bumps.
Why are we working on this? Because this software provides unobserved, secure and easy-to-use connections between sources and journalists β right now, today. Supporting and protecting this vulnerable relationship is a core part of what Blueprint for Free Speech does.
Ricochet is fully-functional, security-audited, already-deployed software currently being used by people today. Updating the Tor version it uses is a critical first step. But there are also other straightforward, necessary improvements to be made.
Ricochet does what it does simply, but well - and reliably. It's pretty amazing it still works after such a period of time without improvements.
Other explorations and hypothetical tendrils are interesting, and weβre always open to discussing them for the future. There are good reasons for exploring things for later. But weβre putting our energies in to refreshing something that is used β and useful - right now, because to us, thatβs the most sensible priority.
If youβre interested, do please join us. You are most welcome! Weβre happy to have people on board who want to come be part of this (and thank you to those who have already been contacting us and helping out!). Watch this space ..
I'm glad you are "open to discussing them for the future" - but, quite frankly, that future was 2 years ago. The space has moved on. The landscape has changed.
Because this software provides unobserved, secure and easy-to-use connections between sources and journalists
Other explorations and hypothetical tendrils
Let me be explicit here, for fear of being misunderstood.
I've already provided a list of a number of issues with the old ricochet protocol & application. Moving to v3 onions completely changes the security assumptions around authentication, simplifies peer management and provides a noticeable speed boost. Adding group support likewise does the same. Open Privacy has done all that work.
Cwtch is the result of that, it is working software with an active base of users and volunteers, a better security model, built on top of v3 onions with group chat & android support (all that exists today in, again, working software)- it has been designed with those use cases in mind, by a team with the technical experience & expertise to deliver in this space for the communities who need this technology, securely.
To see that work described as "hypothetical tendrils", and to effort being poured into repeating work already complete for the sake of reviving software which was already slated for a rewrite is disheartening (to be polite).
And that is neglecting to mention Briar, which has also done a lot of important work in this space, who also have working software and who have also been plugging away in this space solving the problems that arise when extending these protocols beyond where they were in 2016.
Invest energies where you want, that's the beauty of decentralized tech, but from my perspective (which I would hope would count for something, given the time, money & soul I've put into this space over the last several years) ricochetrefreshed represents a step backwards (in security, in UX, in practically every way) to the detriment of the communities that rely on this kind of software.
We've just created a pre-release for Linux, tested on Ubuntu 18.04. We have included the latest version of Tor 0.3.5.8 in the pre-release.
It's at ricochetrefresh.net.
Thank you to everyone who has pitched in to make it happen - we're making good progress.
Enjoy!