Recently discussed offtopic on phabricator was a secure replacement for Pidgin/libpurple known to have a lot of 0days.
xmpp-client is a modern safe library used by the GUI and user facing solution CoyIM for those interested.
Good day,
with TLS and OTR support, it sounds quite good, will look into it.
Have a nice day,
Ego
1 Like
The state of libre federated, asynchronous chat protocols:
Moxie decides to be a complete dick and closes up Signal server code and attacks anyone trying to write and interoperable implementation. See the links in my post:
The Chatsecure devs who are also part of the Guardian Project invent the OMEMO and OX protocols as replacements with the same functionality after Moxie refused to license Axolotl to them. Its becoming the go to alternative.
Coyim refuses to implement it and are waiting for OTRv4 vaporware that supposedly promises the stars. Seeing how OTRv3 never went anywhere and mpOTR flopped - They shouldn’t hold their breath.
1 Like
Signal specs made public for implementors.
1 Like
Still a while before it leaves vaporware but an OTRv4 spec has made an appearance:
2 Likes
Revisiting this topic with another point of view. I think that any easy to use, simple and secure by default IM would be a good addition at this point even with the limitations of OTR. Yes coyIM will never support any other encrypted protocol besides OTR because the dev is stubborn but now the OTRv4 proposal still being actively updated so there is hope for offline messaging in the future.
coyIM is now packaged for Debian Stretch+ so it can be shipped by default in Whonix 14. It forces Tor use AFAICT so it should be readily usable without DNS hackery.
2 Likes
After the small beating Cryptocat’s rep had at the beginning of its life, it has really come into its own. It now supports OMEMO, has underwent a security audit, has well documented code and was used by Snowden in Hong Kong. In other words shits been battle tested
Only con is its not packaged in Debian
1 Like
If it turns out Jitsi supports TCP for VoIP it would be a great option. Then two usecases are supported in one application. OMEMO support in progress. I asked about transports:
It is Debian packaged though in its own repos. It would be possible to drop these packages into the Whonix repo like you do for Tor?
1 Like
HulaHoop:
It is Debian packaged though in its own repos. It would be possible to drop these packages into the Whonix repo like you do for Tor?
Major hassle. At minimum ⚓ T709 port Whonix package build process to Qubes package build process needs to be
sorted first.
1 Like
OK seems the path of least resistance is to add coyIM for now. For VoIP I have a few ideas but they go into another thread and are food for thought in the long term.I opened a pull request which you can keep on hold until pollution of the TransPort is checked out. Any pointers on how to do this?
1 Like
HulaHoop:
OK seems the path of least resistance is to add coyIM for now.
We can add coyIM / merge this early after Whonix 14 release. Should be
easy. Please remind me or create a Whonix 15 ticket as reminder.
until pollution of the TransPort is checked out. Any pointers on how to do this?
Good question. Just now written:
1 Like
Disabled transparent DNS and TCP and coyIM was chugging along happily. Its designed to use Tor by default unless the user goes out of their way to change that.
1 Like
If many 0days exploits are the result, the used language is often one of the reasons.
CoyIM does use Go. They should have used Rust instead.
It’s much safer to program in a secure manner from the ground up by using Rust.
As in lang packs? I was tempted to reconsider it because of OMEMO support but I’ve seen recent advisories for remote code exploits for it even in common code not just an obscure protocol/transport.
Rust wasn’t ready at that point AFAICR. Rust is more of lower level language meant to replace C/C++ while Go is just a more modern replacement for Python. Go had some serious vulns uncovered in it’s ECC libs recently. I don;t think this affects CoyIM though.
The programming language.
It’s easy to make buffer overflows possible in C but as far as i know nearly impossible in Rust.
Fair point.
Well, it’s true, Rust is there to replace C and C++, but it also can be used for normal userspace applications.
Pidgin for example is written in C.
A Pidgin written in Rust would be possible too, but would have a big chance to have much less bugs.
Because some bugs that are possible to write in C are impossible to write in Rust.
The Rust programming language is by itself much safer to use.
The language specific concepts of ownership, borrowing and lifetimes help a lot:
https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html
Good to know. Thanks.