First, securely get a hold of the StartCom root certificate. One easy way to do this is to use Firefox 2.0 to visit this page, and right-click save-as on the StartCom Root CA link. 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. It seems like it would be even simpler to just extract the StartCom root from Firefox’s own storage, since it is already present on your local machine, but I can’t figure out how to do that. Save the file as startcom.crt.

Next:

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

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 cert.

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.)

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.

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.

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.

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.

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..

Time for platform-specific coding fun again.

Initially, Integrity Messenger tried to hire me in May 2002, such that they could acquire the rights to the program. However, I was already bound to a full time job at another company and had to decline. At this point, the guy who was trying to hire me (Christian Rishel) told me that one day I’d get “f*cked”. I didn’t suspect at the time that maybe he meant something about my Psi program. So despite my decline, the company proceeded with their original plan anyway, but without my copyright permission. I didn’t find out about this until August of that year.

This page will become more complete as I add to it.

I suspect the most interesting stuff is the visible evidence, so first up are some screenshots of the graphical interface for Integrity Messenger and Psi, as they would have been sometime in 2002 (shots are of Integrity Messenger 3.36 and Psi 0.8.6, both released in 2002). Note that these similarities may or may not exist anymore, as the interface for Integrity Messenger has undergone many changes over the past 3 years.

Here’s a shot of both main windows, Psi on the right. As you can see, the group headers and system message icon are the same, aside from some graphical adjustments. Also, I’ve opened the right-click menus to show that some of the text and shortcuts are identical (note: the ‘x’ icon for Integrity Messenger’s “Remove” item is also an old Psi icon, although by 0.8.6 we had replaced it with a Trash can).

This one speaks for itself:

Native widgets are a hot issue. Qt works by emulating the widget look & behavior of the platform. Under Windows, this is very easy to do, since the widgets are quite basic. Also, the notion of a “native widget” under Windows is less defined. Many applications get away with having their own widgets, and so the Windows look and feel has never been drastically changed. Even Windows XP, which supports theming, does so by grafting a simple look & feel system atop the usual widgets. Qt supports XP themes quite well. Under X11, there is no such thing as a standard widget. I suppose you could say that would be Motif, and Qt does a fine job of emulating it (even though I can’t stand it), but these days people run all sorts of fancy KDE desktops using advanced styles like Keramik. However, KDE is Qt-native, so this isn’t really any trouble for Qt. Instead of Qt trying to figure out how to look like the desktop, the desktop is telling Qt how to look. Try Qt under GNOME, and we lose all sense of native look and feel. The Mac is by far the most troublesome style to emulate, not just because of complexity (it is complex), but also because it is so high-level that Apple can do things like change the TabWidget look and all apps conform to it. Qt/Mac on Panther (OS X 10.3) shows the older TabWidget style, emphasizing this problem.

Why does Qt not use native widgets? Trolltech will tell you it is more powerful this way. Certainly it is, you can do whatever you want with your Qt widgets, like drawing a line across a button or making your own freaky QScrollBar clone that has extra gadgets on it or whatever. Because the Qt style system breaks down high level widgets into separate parts for rendering, you could actually invent a widget that does not exist on Mac, but still has an Aqua look and feel. However, in many cases, this is overkill. Yes, custom widgets are handy, but do we often need custom widgets that look derived from native widgets? I say no. Consider the ‘BusyWidget’ from Psi, which just shows the logo as a bunch of spinning panels. This is a custom widget. It does not exist on any platform, it is something I wrote. However, it is not something impossible to write without Qt. I could easily make it with Objective-C using native Cocoa and it would look exactly the same. We do not want to rule out custom widgets. What we do want to rule out are customized variations of native widgets. We can trade this flexibility for true native look and feel, which is essentially what the wxWindows toolkit does. So why not just use wxWindows? Well, having native widget wrapping is only part of this battle. Qt is a more ideal framework in my opinion. It is almost like a platform of its own, and even defines extensions to the C++ language like signals, slots, objects, rtti, etc. It turns C++ into a wannabe Objective-C / Java. Whether this is a good idea or not is left up to the reader, but I consider it very powerful to be able to do these extras while retaining the use of C++.

Now, at some point, someone is bound to bring up the issue of the Lowest Common Denominator. This is generally what crossplatform applications have problems with, the rule being that if you can’t do something everywhere, then you just don’t do it. Personally I think this is a stupid limitation. Crossplatform applications should take advantage of platform-specific functionality whenever possible, otherwise the value of the underlying platform is lost. With Qt, we are not stuck in a box. We are natively compiled C++, not confined in a VM like Java, which means we can do whatever we please on each platform. The goal with crossplatform code then, in my opinion, is to have highly portable code, but not necessarily “write once run anywhere” code. We want to share as much code as we can to avoid redundancy, but beyond that we want to write code that is specific to each platform in question.

Consider the text-entry widget on Mac. It has built in on-the-fly spell checking. This is a great move by Apple, and it reminds me of KDE. Instead of simple widgets like on Windows where apps have to supply most of the functionality, apps under Mac can use highly advanced widgets that have a lot of functionality on their own already, and can be upgraded through the OS easily. This allows for more power, consistency, and rapid development of apps. How can we use this widget with Qt? Well, we can’t. This is because QTextEdit, like all Qt widgets, is not a native widget. Could Qt be altered to use the native Cocoa widget? Presumably. At what loss? The ability to do things we would never want, like drawing all over it with QPainter. I think it is clear that in the majority of cases, we would rather use the native widget. Then, of course, we also need a way to access the properties of the native widget so that we can do further platform-specific functions to it. On the Mac, we would like to enable the spell check mode (if we have to do that), but this function would not exist on other platforms. How do you access Cocoa widgets from C++ ? Good question, perhaps it is not easily possible. wxWindows probably does not support this. Qt does not support native widgets, so this is not possible either. So what is the answer, write the whole GUI in Cocoa?

No! Well, sort of. In the end it will all be Cocoa, whether we are creating widgets via Objective-C widgets or using them through a wrapper. However, it is simply not efficient to have to recode everything in Objective-C. Just because you want to port to another platform should not mean rewriting all of your code. The point I made earlier was that emphasis should be placed on code reusability. Some may say that abstracting the GUI completely out of an app is the logical thing to do. In some cases, I agree. If you are porting to a PDA, sure. If you are porting to Mac, you’d probably want to do this to some extent. Licq, the unix ICQ client, has a completely abstracted GUI system, and there are both Qt and Gtk versions. However, there is a ton of redundancy here.

I can appreciate the need to rework a GUI for a particular platform. When you consider the Mac, the GUI design guidelines are drastically different from Windows. Configuration dialogs generally take effect on-the-fly. There are no “OK” or “Apply” buttons. Apps use a global menubar at the top of the screen. Some apps use that weird “brushed metal” look. It is sensible then, that one might want to recreate their GUI completely for Mac. However, consider all of the various dialogs that we have. Do they all need to be recreated on Mac? And if so, do the entire dialogs need adjustment or only partly? For instance, some dialogs might be perfectly fine in their current state, aside from the ordering and alignment of the buttons at the base of the dialog. It would make more sense to reuse the code for this dialog, but to change the button positioning to match the Mac. Why code the use of a scrollbar in Objective-C when you’ve already done it in C++? It’s not like a scrollbar is only available on certain platforms. The solution, then, is to have generic bindings to all native widgets, and also platform-specific bindings so that extra functionality can be used if necessary. Qt is in a great position to do this, and even have fallback to emulated widgets if we really really wanted to make a frankenstein widget with native look. However, for some dialogs it might be more optimal to recode them completely, and this could be done with some Objective-C code wrapped in a C/C++ library. Psi has a ton of backend code, from the XMPP library to all of the internal contact management and accounting. It makes sense to be able to reuse as much as possible when making a MacOS X Jabber client, instead of starting from scratch. However, it should be used in such a way that it is not at the loss of native look, behavior, and functionality.

This, I think, sums up all of my thoughts about cross-platform programming. Rule of the day: code should be as portable and reusable as possible.