Nheko got a lot more colorful this week. red_sky (nheko.im) and LorenDB finished up the jdenticon support. This means instead of the first character of a users display name, you now have the option to see a colorful avatar for users without an explicit avatar. You may have seen something similar on Github and other platforms. Currently this needs the qt-jdenticon plugin, which is a bit troublesome to install correctly, but we should improve that in the near future.

• Prezu added a homeserver entry field to the room directoy, making it much more useful (no history yet though). Thulinma added a /goto command to navigate to specific events or room and fixed scrolling to a specific event (in the past it only approximately scrolled to the right location). Symphorien added the Alt+A shortcut to navigate between rooms with active mentions and notifications. Additionally Priit completed the Estonian translation.

• Additionally we released a security fix on Monday (together with a few other clients). We only released a fix for the master branch in Nheko instead of also the latest stable release. This confused a few people, but I hope my explanations made sense. The gist of it is:

• On the master branch the local homeserver admin could force Nheko to forget which identity keys it saw for a user and as such insert a new device with the same device id, but attacker controlled identity keys and request old encryption keys from Nheko. In Nheko’s case we had some protections against that, but if the server sent a device_list.left event for that user, Nheko would delete those protections. From our understanding this could not be abused over federation.

• On 0.8.2 this can also be abused, but 0.8.2 does not implement key sharing completely. It can only forward the currently in use encryption key, not historical ones. As such the impact in our opinion was too limited to release a security fix. 0.8.2 does not allow you to send encrypted messages only to verified devices as such the homeserver admin could always insert just a different device to get access to new encrypted messages. Because of that we have a big warning in the README and when enabling encryption in 0.8.2, that one should not rely on the security of the E2EE implementation in it. We are aiming to have stable and secure E2EE in the next release (and so far it is looking good), but if you are using 0.8.2 I can only repeat, that it won’t protect you from an attacker even without the disclosed security issue.

I hope this clears up some of the confusion. Feel free to visit us in #nheko:nheko.im and tell me, that I am wrong.