Archive for Psi

Psi 0.13-rc2 released

Psi 0.13-rc2 is here!  Notably, voice calling is now a standard feature of the Windows version.  Please download and test.

Final on July 13th if no showstoppers are found.

New in 0.13
- Voice calls (Jingle RTP).
- Basic XMPP URI handler.
- Ability to permanantly trust certificates at connect time.
- Mini command system (Ctrl+7 in chat window).
- Various bugfixes.

If you are building from source (e.g. on Linux) and want voice calls, you will need to obtain the PsiMedia plugin separately.  On Linux, the plugin file is called libgstprovider.so, and must be put in Psi’s $LIBDIR/psi/plugins directory.  You’ll know it worked if “About GStreamer” appears in the Help menu.

Comments off

Psi 0.13-rc1 released

Psi 0.13-rc1 is here!  Please download and test.

Final on June 6th if no showstoppers are found.

New in 0.13
- Voice calls for Mac OS X and Linux (Jingle RTP).
- Basic XMPP URI handler.
- Ability to permanantly trust certificates at connect time.
- Mini command system (Ctrl+7 in chat window).
- Various bugfixes.

If you are building from source (e.g. on Linux) and want voice calls, you will need to obtain the PsiMedia plugin separately.  On Linux, the plugin file is called libgstprovider.so, and must be put in Psi’s $LIBDIR/psi/plugins directory.  You’ll know it worked if “About GStreamer” appears in the Help menu.

Comments off

Psi in 2009

So Psi moves along sluggishly as usual.  0.13 was not released by Christmas.  There were reasonable explanations for that.  Despite this, I think 2009 will be a good year for Psi, and possibly its best year yet.

I suppose I can’t put words in anyone else’s mouth, but I have high hopes we’ll see Kev and Remko return to regular development after their XMPP book, and that Misha will finally be contributing Yandex stuff back.  As for myself, these past few months stand as a record for the longest time Barracuda let me focus on Psi issues (which, being all Jingle stuff targetting Psi 0.14 or later, is easy to miss).

So, post-book and post-0.13, I predict a sudden surge of visible development, and more attention to submitted patches.

Despite the perception that Psi lags “behind” other client projects, keep in mind we have a number of significant features that have already been started (with major progress) and just need to be finished:

  • Jingle audio and video
  • Whiteboarding
  • WebKit chat windows
  • Revamped message history interface
  • Revamped roster
  • Plugins
  • Bonjour chat
  • Automatic updates
  • Certificate/SmartCard authentication
  • SSO
  • XMPP URIs

Feel free to add more to this list.  I often forget what’s on the back burner.

Do note that the above is not a list of priority features, just a list of features that are partially complete for one reason or another.  The priorities going forward are a topic of a different message.  I just wanted to show that when you count all of this unfinished stuff, Psi is farther along than it appears to be.  The project has been around for so many years, and yet there is still so much to do. :)

Here’s to Psi in 2009!  I look forward to a great year with all of you.

Comments (10)

Introducing PsiMedia

PsiMedia Test screenshot

Voice (and video) chat is a feature we’ve wanted in Psi for a long time.  However, implementing voice/video chat is not straightforward, and this is partly due to all of the new concepts that have to be introduced into the application in order to make it happen.  Cameras, microphones, codecs, and RTP are all just very foreign to Psi.  The code necessary to handle a multimedia “stack” could easily exceed the amount of code in our own IM stack!  Fortunately, there are libraries out there to handle the task.

In 2004, we considered RealNetworks’ Helix framework.  For receiving content, we found this framework to be quite mature.  However, for transmitting content, it was clearly not designed for end-user desktop applications and was even GPL-incompatible in that scenario.  Quite some work went into the Psi+Helix effort, but ultimately it was abandoned.

In 2005, we considered Google’s libjingle.  We managed to get voice chat working with it, but the code never went beyond the experimental stage.  This was due to the limited platform support at the time (Linux audio only at first, though Remko managed to add in Mac audio support) and libjingle’s lack of maintenance.  Libjingle works as a black box, handling not only multimedia but also the Jingle protocol.  Unfortunately, this meant that as the Jingle protocol changed, libjingle fell out of spec.  We also felt it was a tad intrusive for libjingle to be handling XMPP stuff.

In 2006, we investigated GStreamer.  This framework has proved to be the most interesting thus far, for a number of reasons.  Unlike the limited libjingle black-box, GStreamer is a comprehensive and flexible multimedia framework, similar in nature to Helix.  It goes further than Helix though, by offering a better API for transmitting, by being GPL-compatible throughout, and by being easier to extend.  I feel confident we can accomplish everything we need with GStreamer.

Today there is Phonon, however it lacks input and transmission facilities at this time.  We will keep an eye on it for the future.  There is also Farsight, which integrates with GStreamer.  We may make use of Farsight, depending on our needs.

In any case, I’ve started a new “wrapper” project called PsiMedia.  The goal of PsiMedia is to offer an API designed for the purpose of adding voice and video chat to Psi or a Psi-like client.  All of the details the client does not care about will be hidden behind PsiMedia.  It solves only the multimedia aspects, and not Jingle/XMPP, as I consider these two problems to be orthogonal.  Currently PsiMedia wraps GStreamer, but the requirements are abstract enough that the client should not care what is actually wrapped.  PsiMedia can be considered the successor of the old “Media” module I started in 2004, to wrap Helix.

Below are the requirements of the system.

What PsiMedia does:

  • Tell you what audio and video devices are available.
  • Tell you what audio/video modes are possible (codecs, sample rates, video resolutions, etc).
  • Allow you to specify your desired modes, and the modes of the remote party, to arrive at a list if common modes.
  • Capture audio/video and encode as RTP into a series of QByteArrays.
  • Accept QByteArrays containing RTP, and playback any audio/video contained within.
  • Play back video in a QWidget.
  • Allow displaying video currently being captured (preview of yourself).
  • Volume controls.
  • Ability to separate the backend into a plugin, so that no new compile-time dependencies are introduced to Psi.

(RTP, by the way, is a standard packet format for transporting multimedia data in real-time.  It is used by SIP, Jingle, and, well, everybody.)

What PsiMedia does not do:

  • Use the network.
  • Implement Jingle or anything XMPP.
  • Expose anything more than very basic multimedia details.  There are no filters, no pipelines, etc.

In short, PsiMedia should make implementing voice/video chat in Psi straightforward.

Comments (16)

Installing the StartCom root into Debian/Ubuntu

For whatever reason, the ca-certificates package of Debian/Ubuntu does not contain the StartCom root certificates. This may have changed by the time you read this article, but otherwise you’ll probably want to add the root certificates yourself. Here is how to do it the “right way”.

First, securely get a hold of the StartCom root certificates.  (Updated June 27th, 2008) If you have Firefox 3, you can export them from Preferences -> Advanced -> Encryption -> View Certificates.  Otherwise, if you have Firefox 2, then visit this page and right-click save-as on the ca.crt file. It is important that you save-as on the file, because otherwise Firefox will try to import the CA into its own storage and not actually save it to a file like you want.  Save the file as startcom.crt.  If you don’t have at least Firefox 2, or some other already-secured-by-StartCom browser, then you’re stuck going to the above link without protection.  At the time of this writing, the above link only provides the newer startcom certificate.  I don’t know how to obtain the older one other than exporting from Firefox 3.

Next:

sudo mkdir -p /usr/share/ca-certificates/startcom
sudo cp startcom.crt /usr/share/ca-certificates/startcom/
sudo dpkg-reconfigure ca-certificates

Be sure to copy both startcom certificates into the directory if you have them.  In the reconfigure application, choose Ask mode, and select the startcom certificate to have it enabled. You might also take this moment to disable the weird CAs in there. I have no idea how or why Debian decided to trust the CAs that they do. Personally, I enable only the mozilla certs and the startcom certs.

That’s all! StartCom is installed. Now it should work with Psi and Subversion, among other programs.

(Credit to Ralf Hildebrandt for the dpkg-reconfigure hint.)

Comments (2)

QCA and Smartcards

In public key cryptography, it is critical to keep your private key, well, private. One of the major features of QCA 2.0 is support for smartcard devices, and these devices allow convenient and safe storage of private keys. Smartcards perform cryptographic operations in hardware, never revealing the keys to the requesting computer. Traditionally, smartcards have a “credit card” form-factor and require a reader device, but today there also exist smartcards which have the form-factor of a USB mass storage device (they are not “cards” at all). The term “smartcard” can apply to either kind of device, as can “smart token” or simply “token”.

Since QCA has a pluggable backend system, changing out software algorithms for hardware calls is easily possible by writing a proper plugin. However, there is much more to using smartcards than simply substituting a private key call. Smartcards may not always be present in the computer, and may contain many stored keys. QCA offers complete smartcard support, allowing you to discover available smartcards, track inserts and removals, enumerate keys on the devices and prompt for PINs, all using a friendly Qt-based API.

The QCA distribution contains an example application called CMS Signer. It exists mainly to demonstrate using keys from smartcards in a GUI application, although it also works with on-disk keys. CMS, or Cryptographic Message Syntax, is a standard format for storing various types of secure payloads. In the case of the CMS Signer application, the CMS format is used to store digital signature data created from X.509 certificates (fun fact: S/MIME email consists of CMS-formatted parts wrapped in MIME). It is possible to configure and use smartcards completely within the CMS Signer GUI, and I’ll demonstrate this below.

First, we need a smartcard. For this article, I’m using an ePass2000 USB device.

I don’t necessarily recommend it, as I’ve not managed to get it to work under non-Windows operating systems. However, it is cute and it works, and the Windows drivers are available online for free (I find this very convenient, as I’ve managed to misplace the drivers to some of my other smartcard devices…). Most important of all though, is that it supports the PKCS#11 standard. This means the device should be compatible with all other software also supporting the PKCS#11 standard, such as Firefox and QCA.

In CMS Signer, there is a place to perform PKCS#11 configuration.

In here, we must set the path to the PKCS#11 DLL file (on other platforms this may be a .so or .dylib file). For the ePass2000, this is C:\WINDOWS\system32\ep2pk11.dll. There are also some other low-level options you can set, but generally the defaults should be fine. The PKCS#11 provider plugin for QCA was written by Alon Bar-Lev, and it makes use of his pkcs11-helper library, which is where most of these options come from.

It is unfortunate that this configuration step is needed at all, but there is currently no known or standard way to locate a user’s desired PKCS#11 DLL files. You would have to perform a very similar configuration step in Firefox as well.

Now that the drivers are configured, it should be possible to browse for our smartcard.

We can then choose a key:

The key is then imported into a local keyring. It is important to keep in mind that only the public portion of the key is imported. The private portion is not extractable from the smartcard. We can select this key to be used for signing, and enter some data to sign:

… and hit the Sign button, which prompts for a PIN:

… and now the CMS-format signature is generated:

CMS Signer can also perform signature verification, as long as the Text and Signature fields are filled. Since they are filled at this time, we can immediately verify the signature after signing.

Looks good. :)

Both Psi 0.11 and KDE 4 use QCA. In the future, expect to see smartcard support in these projects.

Comments (2)

In-place builds

It may not be widely known that Psi (as well as QCA and Qt) can be built and used “in-place”. This means you configure and make, but there is no ‘make install’ step. This can be convenient if you don’t want to install these packages system-wide.

Of course, you can always just set a prefix within your home directory (or other user-writable area) when building sources if you don’t wish to install system-wide. However, in-place builds are extra convenient for the developer, as it saves the trouble of having to do ‘make install’ every time something is changed.

So while this is not anything new for Psi development, and nor is the idea particularly revolutionary, it might be something you didn’t know you could do and so I’m documenting it here. Personally, I develop everything in-place.

Qt:

Qt 3 is/was always built in-place. You extract it where you want it to end up, configure and make. There is no ‘make install’ step. With Qt 4, they changed it to behave more like other packages. Now the prefix defaults to somewhere in /usr/local, and there’s a ‘make install’. However, the old way is still supported if you pass the directory of where you extracted Qt to -prefix. That is:

$ tar zxvf qt-x11-opensource-src-[version].tar.gz
$ cd qt-x11-opensource-src-[version]
$ ./configure -prefix $PWD
$ make

This is not a hack or a way to trick Qt. It is actually a supported feature, and when Qt is done configuring you’ll notice it says:

Qt is now configured for building. Just run 'make'.
Once everything is built, Qt is installed.
You should not run 'make install'.

Another feature of Qt 4 is that qmake is aware of the installation location. This allows it to locate the necessary files it needs without QTDIR. Additionally, all subtools (e.g. moc) are invoked using their full path. This means you don’t even need the Qt 4 bin directory in your PATH. Finally, if you’re using gcc, qmake also uses rpath when linking. This means you don’t need Qt 4’s lib directory to be specified anywhere either. No need for /etc/ld.so.conf or LD_LIBRARY_PATH. You simply build Qt, go into your project directory, and run qmake.

$ cd /path/to/myproject
$ /path/to/qt/bin/qmake
$ make

QCA:

Like Qt, QCA (as of 2.0 beta2, I believe) supports in-place builds by pointing prefix to $PWD.

$ ./configure --prefix=$PWD

Note: If you’re building against an in-place Qt, and you didn’t put Qt’s bin directory in your PATH, then you’re going to have to tell configure where Qt is. Do this with –qtdir. For example:

$ ./configure --prefix=$PWD --qtdir=/path/to/qt

Unlike Qt, QCA doesn’t use rpath. This may change in the future, but for now you will need to put QCA’s lib directory in your LD_LIBRARY_PATH if you want to use it in-place:

$ export LD_LIBRARY_PATH=$PWD/lib

There’s actually one hidden secret you must do next, and it is sort of cheating. You need to copy crypto.prf into your qmake feature directory. This is so projects that need QCA can find QCA.

$ cp crypto.prf /path/to/qt/mkspecs/features

Fortunately, this file doesn’t ever change, so if you later modify QCA in-place, there’s no need to copy this file again.

QConf:

With the latest development version (as of October 22nd, 2006), qconf can be run without doing ‘make install’. In fact, you can run it from another location, and it locates its data files relative to the executable. This allows it to work similar to qmake, in that you can invoke it by specifying the full path. Unlike qmake, however, this is not dependent on the prefix. That is, you can configure qconf with the default prefix of /usr/local, and you can still run qconf from anywhere without installing it.

$ ./configure --qtdir=/path/to/qt
$ make
$ cd /path/to/myproject
$ /path/to/qconf
$ ./configure ...

Psi:

Psi can be built and used in-place. Once compiled, just run it.

$ ./configure --qtdir=/path/to/qt
$ make
$ ./psi

That’s it!

You can build and use all the Psi tools without mucking with your system, and without ever doing ‘make install’ either.

Comments (2)

Iris and iChat

Ok, so we can do this now:

That’s presence using Link-Local Messaging (a.k.a. Apple’s Bonjour Chat protocol, now documented in JEP-0174). Presence is delivered via local DNS Service Discovery. Chat is done via peer-to-peer Jabber.

Doing Bonjour presence is not all that new actually. The JDNS subsystem has been able to do it since last year. What is notable this time around is that I’m doing it via the new Iris DNS API, which is an abstraction layer, and JDNS is just one possible backend. And there’s also an avatar / buddy icon. That’s good old icon_32.png from Psi. :)

If you want to try it yourself, have a look at the irisnet command-line tool (now committed to the CVS). Quite a few rough edges remain, but it should work. Here is what I ran:

./irisnet pserv justin@ubuntu _presence._tcp 5298
"txtvers=1,1st=Justin,port.p2pj=5298,status=dnd,
msg=coding on iris stuff,
phsh=b12eebe7b5a2f2673aba2f6eb0f3264939a78f67"
-a null:icon_32.png

Yeah, it’s pretty long. :) It is supposed to be a single line, but I’ve broken it up for readability. “irisnet pserv” means to publish a service. Then it goes: JID, service type, port, list of attributes. The -a means to add an extra DNS record, in this case the avatar image (yeah, iChat delivers avatars over DNS, don’t ask questions).

The value of the phsh attribute is the SHA1 hash of the avatar image in hexidecimal. I used the ’sha1sum’ program to do this, which is present on most Linux installations at least:

$ sha1sum icon_32.png
b12eebe7b5a2f2673aba2f6eb0f3264939a78f67  icon_32.png

I don’t know when we’ll see Link-Local Messaging in Psi, but it shouldn’t be too hard to do at this point.

Comments (8)

ServiceResolver

There are three ways Psi might locate a Jabber service. ServiceResolver covers all three, on all platforms, and makes it easy.

To demonstrate how ServiceResolver works, below you can see some output of my ‘irisnet’ commandline tool (which still in development).

The main way to find a Jabber server is via SRV. ServiceResolver looks up the SRV records of a given type on a given domain, as well as the address (A/AAAA) records for each:

$ ./irisnet rservd sapo.pt _xmpp-client._tcp
[213.13.146.7] port=5222
[213.13.146.8] port=5222

You can also lookup non-SRV (”plain”) services. This is done by pre-supplying the port to use, which is returned with each address record found:

$ ./irisnet rservp gmail.com 5222
[216.239.57.107] port=5222
[64.233.161.107] port=5222
[64.233.171.107] port=5222

Lastly, suppose there’s a JEP-0174 / iChat service instance on the LAN called someguy@macbox. In this case, DNS-SD is used:

$ ./irisnet rservi someguy@macbox _presence._tcp
[192.168.1.156] port=5298

There may be three different input methods, but there is only one output method: a list of address & port pairs. The list is always sorted in the order in which the addresses should be tried. Priorities and weights are taken care of for you.

With cross-platform capability, pluggable backends, and seamless Bonjour support, the Iris DNS system is shaping up to be one of the most simple and capable such systems in existence. I suppose I don’t feel so bad about it taking forever to finish, because we really have something cool here.

Comments (3)

Process Termination Handling

I just threw together some code for handling when a process is requested to terminate. The motive is so I can quit a console application cleanly. With GUI apps, detecting when the user wishes to exit is a trivial task, since any GUI toolkit worth anything will tell you when a window closes (via an ‘X’ button or ALT-F4 or whatever). However, console apps, especially those that run indefinitely, and barring those that have interactive UIs such as curses or prompts, are commonly exited by using Ctrl-C. Fortunately, tracking this kind of event wasn’t too bad to implement. Windows has a handler function specifically for console breaking, and Unix has signals (I trap SIGINT, SIGHUP, and SIGTERM, per the glibc manual).

The JDNS commandline tool has an argument to specify how long it should run, which is just plain silly. And my network interface monitoring test program had a similar option too… Until tonight! Now I can just hit ctrl-C and the app will quit. Clean exits are essential when valgrinding, and so this will make my life much easier.

And now that I’ve thought about it some more, this code may also be useful in GUI apps like Psi, for when a system shutdown occurs. However, I think the Windows code I have is for console only, so that will have to be resolved before it is useful there..

Comments

« Previous entries

Bad Behavior has blocked 224 access attempts in the last 7 days.