ayena.de

That's right DIGEST-MD5, your job is done here. Now it's time for the new kid to take up your place.

Those of you who ever tried to actually implement the DIGEST-MD5 SASL mechanism for authentication know that it suffers from quite a few problems, including but not limited to a variety of different implementations with a variable level of compliance to the DIGEST-MD5 RFC 2831. These interoperability problems make it quite hard to get a new implementation working with most of the already existing implementations.

SASL mechanisms are designed to be protocol-independent. That's basically the whole idea about SASL; to abstract the authentication part out of the application protocols, and standardize it. However DIGEST-MD5 already started off on the wrong foot.

Due to Waqas's asking for months now I've finally got around and made some benchmarks on two string prepping libraries. The one being libidn, as far as I know most XMPP servers use this and the other being ICU by IBM.

While libidn is LGPL licensed with ICU you have nearly all freedom with the choice of license for your project, due to MIT license.

Current XMPP standard says that every JID must be string prepped so if you don't want to cache because of memory reasons your string prepping routines are called quite often. It turns out ICU is much faster than libidn. For this benchmark I tested a couple of strings and let them go through nameprep, resourceprep and nodeprep profiles via string prepping.

Since quite a month there is a new XMPP server on the market, called Prosody. Today version 0.2.0 has been released with some new features which you can all read up in the release notes.

Version 0.2.0 has been released just one month after version 0.1.0 and four months after development began. With currently nearly one month between a release and the next we have a good release frequency which is fairly important for a project, especially for one which focuses on ease of prototyping new features in and a protocol around it like XMPP with is evolving pretty fast.

Hi,

here a short and long awaited update on my Google Summer of Code work. I've been finishing the update of libpurple's Entity Capabilities implementation to the latest version and added a bit functionality so that 3rd-party plugins for Pidgin can query for some contact's capabilities or adding capabilities to Pidgin's feature list which they implement. It's been tested and seems to work. Thanks to Arne König for testing all this and giving useful feedback.

Here a long overdue and promised update on my work on libpurple's XMPP protocol plugin.

Currently I'm finishing support for XEP-0115 version 1.5 in the protocol plugin. I've decided to only support latest version of the XEP because it's most secure. However, what does this mean exactly?

Well, former caps worked so you give a version string and so called short names with your presence stanzas. Though shortnames are really obsolete and we already have a registry for features identified by their namespace and the former version of the protocol didn't provide any amount of security. One could tell you that it's Psi or Tkabber and send a whole different feature set and all clients with that version would be associated with the wrong feature set of the poisoned cache.