Security vulnerability and new Toxcore release

Posted on by nurupo

A vulnerability was discovered in Toxcore that allows one to learn the IP of a target user by only knowing their Tox Id and without being friends with the target user.

The Tox protocol is designed in such a way that only friends (contacts) which you have accepted friend requests of are able to learn your IP based on your Tox Id and no one else. Thus, being able to learn the IP of an owner of a Tox Id without them accepting a friend request is an undesired behavior.

This is a vulnerability in an implementation of the Tox protocol, a vulnerability in the Toxcore library, not in the Tox protocol itself.

The vulnerability affects both TokTok’s c-toxcore and irungentoo’s toxcore. The vulnerability affects only UDP mode of operation. TCP-only mode is not affected by the vulnerability.

TokTok’s c-toxcore has patched the vulnerability in version 0.2.2. irungentoo’s toxcore doesn’t have the vulnerability patched as of this moment and it’s unknown if it ever will, as it hasn’t been actively maintained for years. irungentoo’s toxcore was patched after this post was written.

The vulnerability was privately reported to us by Evgeny Kurnevsky on April 14th and publicly disclosed with our permission on April 15th, along with a patch fixing the vulnerability, made by Evgeny Kurnevsky. The vulnerability was found when Evgeny was working on tox-rs project – a Tox implementation in Rust.

We urge everyone to update to the latest TokTok c-toxcore as soon as possible. You can immediately mitigate the vulnerability for yourself by using TCP-only mode.

Due to the nature of the vulnerability, using Toxcore in which the vulnerability is patched is not enough to protect yourself. The way the patch works is that it can’t protect you from the vulnerability but it can and does protect other peers. So in order to be protected from the vulnerability, everyone should switch to using the patched Toxcore. The more people use the patched Toxcore, the less is the chance to be vulnerable. Note that this applies only to the UDP mode. If you use the TCP-only mode, you are fully protected as you are not affected by the vulnerability.

Details of the vulnerability

Here are the technical details of the vulnerability.

The vulnerability is caused by the Onion module of Toxcore erroneously allowing to onion-route any data, any Tox packets, without a restriction. By the Tox protocol specification, when Alice makes an onion-routed request to Bob and then Bob sends an onion-routed response back to Alice, the payload of the onion-routed response sent by Bob arrives to Alice as it is, stripped of any identification that it was ever onion-routed by the last onion hop, and is interpreted as a regular Tox packet by Alice. Alice has no way to distinguish onion and non-onion packets — she has no idea if the packet originated from the node it received the packet from, or if the packet was relayed on someone else’s behalf as part of an onion-routing. The way the onion routing is defined in the Tox specification and Toxcore erroneously not restricting the packets that can be onion-routed allows for some interesting interactions that weren’t meant to happen.

One of the packets that are onion-routed is the Announce Request packet. It’s used to announce ourselves to nodes close to our long term public key, the one that is a part of Tox Id, and the payload of that packet includes the long term public key itself. Let’s say Alice announces herself to a bunch of nodes, one of which happened to be Bob. (If Bob is malicious, he can purposefully keep re-generating his DHT keypair until his public key becomes close to Alice’s long term public key as to guarantee Alice announcing to him.) Based on the Announce Request packet, Bob now knows Alice’s long term public key and has a way to contact her back though the established onion path. If Bob is malicious, he could spawn many new DHT nodes, and send back to Alice a NAT Ping Request packet for one of its newly created nodes. The NAT Ping Request packet is used to ping a node on someone else’s behalf in order to circumvent the NAT. The NAT Ping Request is not meant to be onion routed. Alice will receive the NAT Ping Request packet and will diligently relay it to the Bob’s DHT node if it happened to be in Alice’s Close List of nodes, which will happen only if the DHT public key of Bob’s node is close to the DHT public key of Alice’s node. Bob doesn’t know Alice’s DHT public key, so Bob will have to make a guess. If Bob makes a bad guess and Alice doesn’t relay the packet to his node, Bob can re-try by sending the NAT Ping Request packet to Alice for a new DHT node, repeating this process as many times as he wants. Eventually Bob’s DHT node will have public key close to Alice’s DHT public key and end up in Alice’s Close Nodes list, making Alice relay the NAT Ping Request packet to it, unknowingly disclosing her IP to Bob. Now Bob knows both Alice’s long term public key and her IP without being friends with her.

What the patch does is make all nodes in the onion path check if the payload of the onion-routed response is a packet kind that shouldn’t be routed through the onion, and if so drop it. It also makes the node closest to the destination of the onion-routed request, which is the only node in the onion path of the onion-routed request that can see which packet kind is sent to the destination node, drop the onion-routed request if it has a packet kind that shouldn’t be routed through the onion. The latter doesn’t matter much as Alice can’t exploit Bob in any way by onion-routing him packets that are not supposed to be onion routed, it’s done more for data sanitization reasons.

Because there are only 3 nodes in the onion path, the source and destination excluded, the patch protects you as long as at least one of the three is using the patched Toxcore.

This vulnerability affects only the UDP mode. In TCP-only mode the Onion module restricts which Tox packets are onion-routed correctly, and the Tox protocol specification is written in such a way that nodes using TCP-only mode can distinguish between onion and non-onion packets. So all of the above applies only to the UDP mode.

Update (January 2022): This vulnerability has been assigned CVE-2018-25022 identifier.

Toxcore v0.2.0 released

Posted on by nurupo

We are happy to announce the release of Toxcore v0.2.0. Download the tarballs, verify the signatures and read the changelog on Toxcore’s GitHub Releases page.

Some of the notable changes in this release are: fix for large video frame corruption [1], removal of libtoxdns [2], small API breaking changes in tox.h, toxav.h and toxencryptsave.h [3], [4], [5], [6], [7], [8], API deprecation notices for APIs that will get removed in v0.3.0 [9], and a build script change that results in a single big libtoxcore library being built, instead of separate libtoxcore, libtoxav and libtoxencryptsave like it was before [10]. One of the changes that we hoped would get in v0.2.0 but it didn’t was persistent group chats, but with how things are going it’s set to be added in one of the v0.2.x releases.

Some clients already have support for Toxcore v0.2.0, for example Toxic v0.8.2 and qTox master, while other clients are working on adding the support.

Shutdown of the Debian and Ubuntu package repository

Posted on by nurupo

I’m sad to announce this, but we have to shut down the Debian and Ubuntu package repository due to it being unmaintained and thus having outdated or even possibly broken packages. It has been several months since our last package maintainer maintained any packages and our search for a new package maintainer didn’t result in anything. The package repository is planned to be shut down sometime in the first half of March. The package repository might return in the future if there would be enough people willing to maintain it, but for now we have no choice but to close it.

Contributors wanted

Posted on by nurupo

It’s common knowledge that any open source project wouldn’t mind having more contributors and Tox is not an exception. This blog post is for those who want to contribute but don’t know where to start.

Starting contributing to Tox is as easy as joining #toktok channel on Freenode IRC, which is where majority of the development discussion takes place, and asking what part of Tox would benefit the most given your skill set and interests, unless you already have an idea which part of Tox you would like to help with. Just note that it might take some time for you to get a reply as not everyone is always in the chat, so please be patient. Many Tox developers and community members are connected to the chat 24/7 but get on it only in their free time. Mailing list might sound more appropriate for such possibly asynchronous discussions, and we do have a mailing list, but it doesn’t seem to catch on among developers much, so you will get better response on IRC.

Here is a non-exhaustive list of things you could help with, just to give an idea.

Non-programming

You don’t have to know programming in order to help. You can help by testing nightly builds of clients and translating clients to different languages.

Testing clients

You can help by testing nightly builds of Tox clients, the in-development, yet to be released, versions of clients, and reporting any problems you encounter to the developers. Testing nightly builds can help to find bugs and get them fixed before a release is made. Some clients don’t have nightly builds available for testing, or they do but they are not well maintained and might be broken. If this is the case for a client you want to test, simply asking developers for nightlies should resolve this issue. Also, even if the client you test is non-nightly, your testing is still useful. Just make sure that you are testing the latest release version of the client, as any issues you encounter might have been fixed in a newer version. You can get a client to test from the Download page of our website. You can provide feedback to the client developers by opening an issue in the client’s issue tracker, which is generally located on the client’s repository page. When reporting feedback, especially bugs, is a good idea to provide as much information to the developers as possible: operating system you are running and the version of it, the version of the Tox client you are running, exact steps on to how to reproduce the issue you are having and what you have expected to happen instead when you took those steps.

Translating clients

Some of the clients support multiple languages in their user interface, you can help translate the user interface to any language you know and correct existing translations if you find them unsatisfactory.

Here are links for some of clients:

Programming-related

Software development

Anyone with programming background is welcome, as we have quite diverse codebases. We could use help of people familiar with any of C, C++, Go, Haskell, Java, Python, Rust, Scala, Swift and other. Familiarity with networking, peer-to-peer software design, distributed hash table, cryptography and writing secure code is preferred, but not required for all of the codebases we have. You can help with an existing software project or start a new project of your own that would be useful to Tox. Also, you don’t have to write code to contribute. Reviewing the code that is considered for merging into the codebase is also a great way to help.

Website development

We are in need of a website developer/designer or anyone familiar with HTML, CSS, Bootstrap, Jinja 2 templates and Python. The person currently maintaining the website is more of a C++ developer than a web developer, so while they keep the information on the website up-to-date, doing more involved changes, like changing the page layout, is something that is hard for them. The Tox website doesn’t use anything fancy, we try to keep it as simple as possible: it’s a static page website which uses Jinja2 template engine and Python for page generation. We limit the use of JavaScript to the point that the website is perfectly functional without it while enabling it adds optional enhancements.

Packaging

We are in need of package maintainers (to the point that we don’t have packages for Ubuntu 17.10 (Artful) at all), anyone familiar with shell scripting, building software, debugging and fixing failed builds and creating packages is welcome. We maintain Debian and Ubuntu package repositories, with packages being created using pbuilder, so familiarity with pbuilder helps.

Join #toktok and become a contributor today!

Update on Toxcore and the upcoming breaking version

Posted on by nurupo

Hello everyone! Time flies fast, we spent all of 2017 without any status update, so a blog post is due, especially given that we are about to hit a new milestone and introduce some breaking changes.

Since our last blog post about Toxcore getting a stable version release, version 0.1.0, Toxcore has seen eleven more releases, which brings it to the version 0.1.11. Some of the notable changes in these releases include: (a little) reduction of bandwidth usage [1], [2], fix of issues related to reconnecting [3], improvement of LAN discovery [4], ability to disable LAN discovery [5], fix of the read receipts sometimes never arriving [6], reduced video corruption [7] and better support of the FreeBSD platform [8], [9], [10], [11], [12] and the Microsoft Visual C++ compiler [13], [14], [15], [16]. Aside from these, there were also many other bug fixes and code maintainability improvements.

The next Toxcore release that is planned after 0.1.11 is 0.2.0. Toxcore versioning scheme follows that of Semantic Versioning with x.y.z versions with leading zeros being stripped, meaning that 0.1.0 has the same API promise as 1.0.0. Which means that 0.2.0 will be a breaking release, it will break the compatibility with 0.1.x versions. Some of the breaking changes planned for 0.2.0 include: removal of the toxdns library [17], building resulting in just a single Toxcore library file containing all sublibraries’ code [18] and toxencryptsave library’s API breakage [19]. Other breaking changes might be added as the work on 0.2.0 release goes on.

It’s worth to note that since our last Toxcore blog post the adoption of the TokTok Toxcore fork of the original Toxcore has been going well and all of the actively maintained clients have switched to using it as their Toxcore library.

That’s all with updates on Toxcore.

As usual, happy Toxing!

Bug in musl-libc discovered, affecting the fully static Toxic builds

Posted on by nurupo

We advise everyone using the fully static Toxic builds that are listed on our download page to update them to the newest version by re-downloading them from that page. Those Toxic builds use musl-libc and there was a fairly serious bug discovered in musl-libc (CVE-2017-15650) and patched yesterday . The new Toxic builds include this patch. This affects only the fully static Toxic builds, no other builds currently use musl-libc.

First Stable Release of TokTok Toxcore

Posted on by oranges

Good news everyone!

The first stable version of TokTok Toxcore, 0.1.0, got released. This release will be API compatible with other 0.1.x releases, until 0.2.0 is released, which will break the API.

This marks the first stable release of TokTok Toxcore and is an exciting milestone on the road to future Toxcore improvements.

The packages of TokTok Toxcore are now available in the stable and nightly streams on pkg.tox.chat.

Most clients are switching to using TokTok Toxcore as their Toxcore library. Antidote and µTox clients already use TokTok Toxcore, qTox has gained support for TokTok Toxcore and will use it in the next release, and Antox and Toxic are in the process of gaining support for TokTok Toxcore.

Thanks to iphy, grayhatter, nurupo and others for their hard work on Toxcore, as well as thanks to Encrypt for the work on packaging it.

TokTok Toxcore version follows the rules of Semantic Versioning. The API promise of x.y.z version is defined to be the same as the Semantic Versioning API promise of x.y.z with leading zeros stripped, meaning 0.1.0 has the same API promise as 1.0.0.

While we were being excited with the 0.1.0 release, TokTok Toxcore has already released 0.1.1 version. The current release cycle of patch versions is approximately one per week, so they keep incrementing relatively fast.

Happy Toxing!

Update: Ubuntu Yakkety packages, Tox in App Store and Toxcore updates!

Posted on by nurupo

Hello everyone! Some of you have requested us to make a status update, so here we go.

Packaging

Quite a bit has happened with Linux packaging this month.

Packages for Ubuntu Yakkety (16.10) are available. Our packaging team prepared for the new Ubuntu release beforehand, packaging clients for Ubuntu Yakkety while it was still in the beta, so all of our clients were available for Ubuntu Yakkety on the day of its release.

Packages for Ubuntu Vivid (15.04) and Ubuntu Wily (15.10) were removed. We have mentioned in the previous blog post that we would like to remove them at some point, as Ubuntu Vivid and Ubuntu Wily have reached EOL, and addition of packages for the new Ubuntu release served as that point.

Empty package repositories were removed. These repositories existed because we considered packaging for them at one point, but because of cross-compilation complexity and lack of required dependencies on older distribution versions we decided not to package for them. For example, we didn’t have any packages for armel architecture and for Ubuntu Trusty release. This caused some confusion as some Tox users would see these package repositories available and add them, thinking that they contained Tox clients, when in fact they were empty.

qTox packages were removed from all package repositories. In the previous blog post we mentioned that Encrypt was going to take over the maintenance of qTox packages, but because of personal reasons he is not able to volunteer as much of his free time as he hoped he could. We decided that it’s a bad idea to serve unmaintained packages to our users, so we had to remove them. Although there are no more qTox packages in our https://pkg.tox.chat package repository, you can still get qTox packages from the openSUSE Build Service package repository, which qTox developers advertise as the recommended place to get qTox packages, and which is linked on the Download page of our website.

iOS

Antidote, the Tox client for iOS developer by dvor, is now on the App Store. Get it, try it out and send your feedback to Antidote’s developer by either writing a review on the App Store or submitting a bug report/feature request to the issue tracker!

Toxcore

irungentoo/toxcore

Not much has happened with irungentoo/toxcore. Incorrect permissions set by tox-boostrapd[1] and bug in LAN discovery code[2] were fixed. A bug in development branch which resulted in a crash of Toxcore[3] was fixed.

TokTok/c-toxcore

A lot of internal changes were done in TokTok/c-toxcore in order to make it more testable and to improve the code quality in general. Compliance with the C standard was improved[4]. Callbacks thoughout Toxcore have become stateless (ToxAv is comign next), which will help with bindings for the languages with managed memory[5]. ABI backward compatibility support was improved [6], [7]. Toxcore was made compatible with C++, allowing us to use C++ compiler to catch some type casing issues [8], [9]. The existing test suite was improved [10]. Group chat API was rewritten to follow the guidelines of the current API[11]. Generally a lot of other code improvements happened.

To allow easier transition of clients from irungentoo/toxcore to TokTok/c-toxcore, 0.0.1 version of TokTok/c-toxcore was released, which would make it possible for clients to support both Toxcores at the same time. µTox nightly has already transitioned to using TokTok/c-toxcore, which means that the next release of µTox will be using TokTok/c-toxcore. Antidote, Antox and qTox also have plans on switching to TokTok/c-toxcore.

Support for UPnP and NAT-PMP is coming to Toxcore soon. UPnP and NAT-PMP are port forwarding mechanisms, they allow programs to automatically setup a port forwarding rules on users’ routers without users having to manually do this. This solves the issue of routers not allowing someone you have not communicated with before to send you data, improving Tox’s networking performance, as the hole punching workaround would not be needed to get around this anymore.

That’s all that has happened during last couple months, until the next update!

Update: New client, Xenial packages, Tox in Google Play, Toxcore fork and more!

Posted on by nurupo

Hello everyone! It’s been more than two months since the last update and quite a few things have happened since then, so an update is due.

Website

A new client has been added to our website — Toxygen. It’s written in python and uses Qt for its UI. Give it a try and see if you like it. You can get it for Windows and Linux from Toxygen’s Releases page. We also provide Debian and Ubuntu packages for it in our nightly package repository.

Packaging

Thanks to Encrypt’s and tux3’s efforts, we now provide packages for Ubuntu Xenial. As of writing this, the following client packages are available in nightly Xenial: Toxic, Toxygen and uTox.

New packages were added to our package repository: uTox, Ricin and Toxygen. While we did package uTox before, it was just a static binary, whereas now we have proper shared binaries made for target distributions. Ricin is currently available only in the stable repository, but should soon also be available in the nightly.

If you have been following qTox blog — and yes, qTox got its blog, we recommend you follow it if you are a qTox user — you should know that qTox has moved from distributing Linux packages through our packaging infrastructure to using openSUSE’s Open Build Service (OBS) platform, mainly as OBS allows to create packages for more Linux flavors than just Debian and Ubuntu, such as Fedora, openSUSE, CentOS and a few more. Because of this, tux3, the main qTox developer, has stopped maintaining qTox Linux packages in our package repository, but he is against removing them just yet to allow for smoother transition of users to OBS. Encrypt, the other packaging enthusiast, has said that he is willing to maintain qTox packages in our package repository in tux3’s stead, which tux3 is not against, and he will look into adding support for .rpm packages (used by Fedora, openSUSE, CentOS, etc.) to our infrastructure. Packaging is a surprisingly hard and arcane process, so if you have experience with creating proper .rpm packages in target distribution’s chroots, we could use some help — please email Encrypt.

Using Tox package repository

Just as a reminder, here are instructions on how to get our packages on Debian and Ubuntu systems.

We currently support Debian Jessie (8/stable), Debian Stretch (9/testing), Debian Sid (unstable), Ubuntu Vivid (15.04), Ubuntu Wily (15.10) and Ubuntu Xenial (16.04 LTS), i386 and amd64 architectures. To add our package repository, run the following commands, replacing TRACK with either stable or nightly and replacing RELEASE with one of jessie, stretch, sid, vivid, wily or xenial, appropriate for your Debian/Ubuntu release. Packages in the stable track are generally updated whenever a client releases a new version, and packages in the nightly track are updated once a day with the most recent development progress, if any.

echo "deb https://pkg.tox.chat/debian TRACK RELEASE" | sudo tee /etc/apt/sources.list.d/tox.list
wget -qO - https://pkg.tox.chat/debian/pkg.gpg.key | sudo apt-key add -
sudo apt-get install apt-transport-https
sudo apt-get update
# List all client packages available
grep -h 'Package: ' /var/lib/apt/lists/pkg.tox.chat* | grep -v ' lib'

There is also a special RELEASE called release available, which provides statically built versions of some of the clients. It’s not very well maintained, it’s there mostly for historic reasons, as this was the very first release name we had in our package repository and we advertised it to users. If you are on one of the supported Debian/Ubuntu releases mentioned above but you use the release release, we advise to switch to the release appropriate for your Debian/Ubuntu version.

In the future we plan on making nightly packages to be updated as soon as developers push new code for them, which might happen more frequently than once a day. We also plan on dropping Ubuntu Vivid and Ubuntu Wily support at some point, as those Ubuntu releases have reached their end of life, and adding support for Ubuntu Yakkety.

Android

Antox got published on Google Play. Previously Antox was available only though our F-Droid repo, Google Play testing and as a direct APK download, but now everyone can easily find and download it through Google Play. While we believe that it might be a bit too early to make it publicly available for everyone, given that Toxcore is not optimized for mobile yet: it uses a lot of data and keeps CPU busy, resulting in increased battery usage, which might turn people away from Tox, the Antox developer decided that it’s the perfect time to publicly release it, so here we have it. Install it, test it and report any issues to Antox issue tracker.

Shockingly enough, uTox also got published on Google Play. uTox is a native Linux application, not an Android application, made to run on Android. As such, you can expect it having UI different to what regular Android applications have, to the point that it might be not very usable. It’s surprising to see it being released on Google Play, as uTox for Android was created as a joke, just to prove that you indeed can run it on Android, it wasn’t supposed to be used by anyone. You can give it a try if you feel adventurous enough, and report bugs to uTox issue tracker, but we’d suggest waiting for uTox to be properly ported on Android as an Android application, rather than a generic Linux application.

The story goes that Antox developer didn’t want to publish Antox on Google Play until Toxcore becomes more mobile friendly, so the uTox developer published uTox to Google Play just to provoke Antox developer publishing Antox. Such mind games our developers play with each other.

Toxcore

Toxcore’s developer, irungentoo, has been very busy lately and unable to find time to work on Toxcore. Because any change to Toxcore should be first reviewed and approved by irungentoo, as he is the only one who can merge changes, Toxcore development has been stalled for some time now. To get around this, a non-hostile Toxcore fork was created by iphy, where the development is currently ongoing.

You might have noticed that the fork was created in TokTok GitHub organization. What is TokTok? TokTok initially was one of Google Summer of Code 2015 projects mentored by iphy, specifically it was the New Android Client project (GitHub repository). iphy has extended the idea since then greatly, to the point of making it a distributed storage and computing platform, but the fact that it’s still built on top of Toxcore remains unchanged. Why is the new Toxcore fork in the TokTok GitHub organization? iphy was quick on forking Toxcore, setting up automated testing and review system, opening bug reports and adding code contributions, so that before we could even get iphy to explain what the fork is about and decide whether we should support it and move it to the Tox GitHub organization, it has already became problematic to move it to Tox organization because everything would need to be re-setup again, so we just left it there, at least for now. We might move it to the Tox GitHub organization later, but for now we don’t really care where it is, what we care is improving Toxcore.

The current goal that we work towards in the forked Toxcore is to test whether Toxcore does what the Tox specification says it should be doing. Since the Tox specification was written after the Toxcore implementation was made, not the other way around, Toxcore currently has no specification-based tests. Having a specification testing framework would allow us to test Toxcore and any possible future Tox implementation against the claims made in the Tox specification, which also would allow for an easy way of extending the Tox specification and having those extensions tested. This goal also would allow us to get more familiar with Toxcore codebase, as previously only irungentoo had a good knowledge of it. After the specification-based testing will be complete and we become familiar with Toxcore codebase, we will be able to proceed with including new features into the Tox specification and implementing them.

Multidevice

Multidevice support is not yet complete, Grayhatter and several other contributors are still working on it. Some of the things that need to be done include support of synchronization of video and audio calls, file transfers and friend deletion actions.

New group chats

New group chat support is currently not being worked on by anyone. As you might have read from the previous update blog post, the new group chats are almost fully implemented in JFreegman’s Toxcore fork, the only thing needed for them to work properly is the TCP-DHT support by Toxcore. Irungentoo has said that he will work on adding TCP-DHT to Toxcore, but as he has been busy, he never got to adding TCP-DHT to Toxcore and we don’t know when he will have time to do that. Also, because the current goal of the Toxcore fork is to be fully tested against Tox specification, and both TCP-DHT and the new group chat are not (yet) part of the specification, we can’t implement them before we are done with the testing, as implementing them would make Toxcore behave in a way that is not conforming with the current Tox specification. For now we are trying to avoid modifying Toxcore behavior, until we are done with the specification-based tests. We believe that with irungentoo being less active, having specification-based tests and good understanding of Toxcore is a good investment of our time before we move to implementing other features, such as TCP-DHT for the new group chat, so don’t be upset if your favorite feature didn’t make it in, we are slowly but steadily working on it.

That’s all for now, until the next time!

Update: New group chats, multi-device, and more!

Posted on by Jfreegman

Hey everyone! It’s been a while since our last update, so we’d like to get everyone up to speed on what’s been going on in terms of Toxcore development and community happenings.

One of the most discussed topics in the Tox community over the past few months has been the release of the new group chats. Unfortunately, there is still no ETA. I finished writing the code base about 6 months ago and they’ve been available for testing for some time via my new groupchats branch. However, it’s still missing one crucial thing: TCP support.  The new group chats cannot be merged without TCP-DHT support in the core, which is currently being worked on in a private branch by the lead core developer, irungentoo. The latest word is that DHT is currently working over TCP, but he’s still having issues with bugs and failing tests. We know how eager everyone is to finally be able to try out the new group chats, and we want the community to know that work is being done and progress is being made.

In other news, Grayhatter, along with the support of Tux3, is working on another widely requested feature for Toxcore—Multi-device support. It’s still in a very early, hardly-working stage of development, but if you like the idea of testing extremely buggy code that may or may not delete your profile, you can try the Multi-device version of µTox. (Note: backup your save.tox profile first.)

Finally, we would like to offer a heartfelt thank you to LittleVulpix for stepping up to the plate and taking over toxme.io after its original owner no longer had the ability to maintain the service. Additionally, we want to thank Encrypt, who created a packaging script, and with the help of Tux3 has adjusted the script to work on our build infrastructure.

That’s it for now, but hopefully we’ll have some more announcements for you in the near future. Happy Toxing!