Coding: Python, GNOME-Keyring, and GObject Introspection

Nowadays, the fragmentation of the free desktop is a much smaller issue for developers than it was some time ago. With specifications like XDG Base Directory and efforts like QGtkStyle, creating an application that does not behave or look alien in most big players like GNOME and KDE is relatively simple.

But when developing Polly, I found out that there was one field where fragmentation is still a major problem: storage of sensitive information. GNOME has GNOME-Keyring, KDE has KWallet, and those two don't speak the same language at all. Luckily, I came across a lovely library called python-keyring that takes care of all the dirty work by automatically detecting the environment and choosing a proper keyring. I even talked about it in my Ubuntu App Developer Week session

This approach is not without its problems, though. The library falls back to its own encrypting implementation when it does not detect any supported keyring, and requires the user to type an unlocking password via terminal in this case. This is obviously an usability fail for any user that does not use GNOME or KDE.

Furthermore, the library depends on the static Python bindings to libgnome-keyring, which in turn depend on the static bindings to GObject. This conflicts directly with my current work of porting Polly to GTK3 and therefore PyGI, because static and introspected bindings cannot be used together. Some googling revealed that the developers were aware of the issue but could not do much because libgnome-keyring is hard to introspect.

I really didn't want to postpone the GTK3 porting by another cycle, so my frustration grew to a point where I actually asked Matthew Paul Thomas whether requiring to type a password on every start would be a good idea. My idea was basically writing a graphical interface for the python-keyring fallback. His answer was no. Among other followers, it was more diverse: it varied between no, no, and no. Despite its overwhelming popularity, I decided to ditch the idea. After Lars offered me support on IRC, I started to consider the risky route of trying to introspect libgnome-keyring.

There was light at the end of the tunnel, though: for a long time now, GNOME-Keyring and KWallet developers have been drafting a DBus-based Secret Service specification. I didn't pay much attention to it first because it isn't final, but then I learned that the GNOME-Keyring daemon is already being backed by it. This was perfect: I could use DBus directly, bypassing the need for libgnome-keyring bindings.

Only one problem, though: I used to rely on dbus-python for DBus work, and this library had too the problem of depending on deprecated bindings. So I realized I had to face the introspected GDBus bindings and cringed at the non-pythonic syntax that was expecting me.

And then, after some more googling... a wild Martin Pitt appeared! Thanks to Martin, my GDBus experience in Python has been much more pleasant than I expected. That was really the last piece of the puzzle. Now I could access GNOME-Keyring via the DBus Secret Service API elegantly, and without ever leaving GObject Introspection.

I still have to support KWallet for a while, until KDE's migration to KSecretService is completed. But since the Qt4/KDE4 bindings do not cause any conflicts, this is no biggie. The main code is now as simple as

    if FDOKeyring.supported():
        keyring = FDOKeyring(UID)
    elif KDEKeyring.supported():
        keyring = KDEKeyring(UID)
    else:
        exit('No supported keyring seems to be accessible.')

Followed by occasional calls of

    keyring.get_password(username) 

    keyring.set_password(username, password, callback)

and so on. What was particularly nice about this whole experience was not only how much I learned, but also the warm and fuzzy feeling that I'm really standing on the shoulders of a lot of giants. Kudos to everyone involved in the libraries.