GnuPG and CCID support

As many of you probably know already, I use GnuPG with OpenPGP cards not only for encryption but also for SSH access. As some or others probably noticed on Twitter, I recently decided to restore to life my old Dell Latitude laptop, but since it’s a fairly old system I decided to try running something else rather than Gentoo on it, for the first time in many years. I settled on Antergos, which is a more user friendly install option for Arch Linux. Since I know a number of current or past Arch Linux developers, it seemed fitting.

Beside the obvious problems of Arch not being Gentoo, the first biggest problem I found was being unable to use the smartcard reader in the Dell laptop. The problem is that the BCM5880 device that this laptop comes from, is not quite the most friendly CCID device out there. Actually, it might have a better firmware available but I need to figure out how to install it, since it requires a Windows install and I don’t have one on this laptop.

But why did this work fine with Gentoo and not fine with Arch? Well the answer is that the default install of GnuPG from pacman enables the GnuPG own CCID driver. In my original drawing on the matter I did not capture the fact that GnuPG has its own CCID driver — although I did capture that in a follow-up diagram. This driver is fairly minimal. The idea is that for simple devices, where they implement the standard pretty closely, the driver works fine, and it reduces the amount of dependencies needed to get a smartcard or token working. Unfortunately the number of devices that appear to implement the CCID standard correctly is fairly low in my experience, and the end result is that you still end up having to use pcsc-lite to get this to work as intended.

Luckily, Arch Linux wiki has the answer and you do not need to rebuild GnuPG for this to work. Yay.

It may be easy to say “fix GnuPG” but the list of devices that are not CCID compliant is big, and Ludovic already has workarounds for most of them in the CCID driver. So why should that list of broken devices be repeated somewhere else? There really is no need. if anything, you may ask why the CCID driver is not an interface-independent library that GnuPG can just access directly, and there are actually a few good reasons why this is not the case. The first of which is that it would be pointless to depend on the small driver but not the pcsclite package that implements the otherwise more widely available interface.

As it turns out, though, the particular Gemalto device I use as my primary card card nowadays is actually pretty much CCID compliant, so it could be used with the GnuPG’s own CCID driver, sparing me the need to install and maintain pcsclite and ccid on my other laptop. Which would also mean I could avoid maintaining the packages in Gentoo even. But here is one of the biggest catches: the devices are not by default accessible to the console user. Indeed even when I made it easier to use pcscd and ccid a whopping six years ago, I only set up the udev rules when the CCID driver was installed.

You could expect systemd to just install by default a rule that allows CCID standard devices to be accessible to the console user, and that would make it possible to use GnuPG and its CCID driver with whichever common standard-compliant devices are available. Which I hope (but I have not tested) include the YubiKey 4 (don’t care aobut the NEO, since then you need to make sure to also have the right firmware, as the older ones have a nasty PIN bypass vulnerability.

But then again, I wonder if there are any security issue I don’t really expect that may be impeding a plan like this. Also, given the much wider compatibility of pcsclite with the devices, not only for CCID but for other non-standard protocols too, I would rather be interested to know if you could run pcscd as a user directly, maybe with proper systemd integration — because if there is one good thing about systemd is the ability to run proper per-user services, in a standardised fashion rather than having to fake it the way KDE and GNOME have done for so many years.

As for maintaining the packages on Gentoo, it is not bad at all. The releases are usually good, and very rarely problems came up during packaging. Ludovic’s handling fo the one security issue with pcsc-lite in the past few years has been a bit so-so, as he did not qualify the importance of the security issue in the changelog of the new release that fixed it, but except for that it was punctual and worked fine. The main problem that I have with those tools is having to deal with Alioth, which has this silly idea of adding an unique numeric ID to each file download, and then providing you with the file with whichever name you provide it when you download. Which effectively means you need to update the ID from the Alioth website every time a new release comes up, which is actually annoying.

On stabling hardware-dependent packages

I thought I wrote about this before but it looks like I didn’t. And since this was something I was asked about a few months ago as well, any time is good to fix the issue by writing what I think about this.

We could say that almost every package in the tree relies on someone having at least some pieces of hardware: a computer. At the same time, some packages require more particular hardware than others: drivers, firmware, and similar packages. The problem with these packages is that, unless you own the hardware, you have no way to know that they work at all. Sure you can be certain that they do not work, if they fail to build, but the opposite can’t be confirmed without the hardware.

This is troublesome to say the least, as sometimes a given hardware driver’s ebuild is written, by either a developer or an user (that goes on to proxy it), when they have the hardware … but it goes untouched once said hardware is gone for good. This happened to me before, for instance I no longer have a Motorola phone to test those handlers; nor I have an HP printer any longer, so there goes my help to the hplip package…

At the same time it is true I have quite a few hardware-dependent packages in the tree still: ekeyd, iwl6000-ucode, and so on so forth. One of the packages I still try to help out with even though I had to discard the related hardware (for now at least) is freeipmi, which exemplifies all too well the problems with hardware-dependent packages.

FreeIPMI, like the name leaves to imply, is an implementation of utilities and daemons to manage IPMI hardware, which is used on middle-range-to-high-end server motherboard for remote management. I had one on Yamato until recently, when either the mainboard or the PSU started to act up and I had to take it out. I had tried to making the best out of the ebuild since I had access to an IPMI board, and that consisted mostly on bumping it, fixing the build and, recently, updating its init scripts so that they actually work (in the case of the watchdog service I ended up patching it up upstream, which meant having something that actually works as intended!).

Last year, after about two years from the release of the version that was marked stable, I decided to ask for a new stable with a version of the package that surely worked better … which is not the same to say that it worked perfectly. Indeed, now I know that said version simply did not work in some configurations, at all, because the bmc-watchdog init script, as I said, did not work and required upstream changes.

What happens when I ask for a new stable this year, to cover for that issue? Well, this time around the arch teams finally decided to test the stuff they mark stable, but that also meant nobody was available to test IPMI-related packages on x86. Even our own infra team was unable to test it anywhere else beside amd64, with the end result that after months of back-and-forth, I was able to get the old package de-keyworded, which means that there is no longer a “stable” freeipmi package; you’ve got to use ~arch.

Don’t get me wrong: I’m not happy about the conclusion, but it’s better than pretending that an ancient version works.

So when Vincent – who proxy maintains the acr38u IFD driver for pcsc-lite – asks me about marking his ebuild stable, I plan on writing this very post.. and then leave it there for over five months… I apologize, Vincent, and I don’t think I have enough words to express my trouble with a delay of such proportions.

And when I get Paweł’s automated stable request for another pcsc-lite driver, my answer is an obvious one: does anybody have the hardware to test the package? I’m afraid the answer was obviously no… unless Alon still has said reader. End result is the same though: time to de-keyword the package so that we can drop the ancient ebuild, which is definitely not adhering to modern standards (well okay, -r2 isn’t much better, but I digress).

Of course the question here would be “how do you mark stable any pcsc-lite related software at all this way?” … and I don’t really have a real clear answer to that. I guess we’re lucky that the ccid driver covers so many hardware devices that it makes it much more likely that somebody has a compatible reader and some card to test it with… the card part is easy, as I suppose most people living in the so-called Western world have an ATM or credit card… and those have a chip that can be at least detected, if not accessed, by PC/SC.

There is actually a script written in Python that allows you to access at least some of the details on EMV based cards.. the dependencies should all be in Portage, but I didn’t have time to play with the code for long enough to make sure it works and it is safe to use.

There is another obvious question of course: “why don’t you stable your own stuff?” — while this could be sensible, there is a trick: my “desktop” systems – Yamato, Titan (this box) and Saladin (the laptop) – are all running ~arch for as long as I can remember… or at least part of it; I gave up on glibc-2.14 so it is masked on all of my systems, on count of breaking Ruby and I’m still pissed by the fact it was unmasked even if that was known.

Any comment to help picking up a direction about this kind of trouble?

Additional notes about the smartcard components’ diagram

Yesterday I wrote about smartcard software for Linux providing a complex UML diagram of various components involved in accessing the cards themselves. While I was quite satisfied with the results, and I feel flattered by Alon’s appreciation of it, I’d like to write a few notes about it, since it turns out it was far from being complete.

First of all, I didn’t make it clear that not all cards and tokens allows for the same stack to be used: for instance even though the original scdaemon component of GnuPG allows using both PC/SC and CT-API to interface to the readers, it only works with cards that expose the OpenPGP application (on the card itself); this was a by-design omission, mostly because otherwise the diagram would have felt pretty much unreadable.

One particularly nasty mistake I made related to the presence of OpenSSL in that diagram; I knew that older OpenSSL versions (0.9.x) didn’t have support for PKCS#11 at all, but somehow I assumed that they added support for that on OpenSSL 1.0; turns out I was wrong, and even with the latest version you’re required to use an external engine – a plugin – that makes the PKCS#11 API accessible to OpenSSL itself, and thus the software relying on it. This plugin is as usual developed by the OpenSC project.

Interestingly enough, NSS (used by Firefox, Chromium and Evolution among others) supports PKCS#11 natively, and actually seem to use that very interface to access its internal storage. Somehow, even though it has its own share of complexity problems, it makes me feel much more confident. Unfortunately I haven’t been able to make it work with OpenCryptoki, nor I have found how to properly make use of the OpenSC-based devices to store private and public keys accessible to the browser. Ah, NSS seem also to be the only component that allows access to multiple PKCS#11 providers at once.

Also, I found myself considering the diagram confusing, as software providing similar functionality was present at different heights in the image, with interfaces consumed and provided being connected on any side of the components’ representation. I have thus decided to clean it up, giving more sense to the vertical placement of the various components, from top to bottom: hardware devices, emulators, hardware access, access mediators, API providers, abstractions, libraries and – finally – user applications.

I also decided to change the colour of three interface connections: the one between applications and NSS, the new one between OpenSSL and its engines, and the one between OpenCryptoki and the ICA library (which now has an interface with a “S390” hardware device: I don’t know the architecture enough to understand what it accesses, and IBM documentation leaves a lot to be desired, but it seems to be something limited to their systems). These three are in-process interfaces (like PKCS#11 and, theoretically, PCS/SC and CT-API, more to that in a moment), while SCD, agent interfaces, Trousers and and TPM are out-of-process interfaces (requiring inter-process communication, or communication between the userland process and the kernel services) — I don’t know ICA to tell whether it uses in or out of process communication.

Unfortunately to give the proper details of in-process versus out of process communication, I would need to split up a number of those components in multiple ones, as all three of pcsc-lite and OpenCT use multiple interfaces: an in-process interface to provide the public interface to the application, and an out-of-process interface to access the underlying abstraction; the main difference between the two is where this happens (OpenCT implements all the drivers as standalone processes, and the in-process library accesses those; pcsc-lite instead has a single process that loads multiple driver plugins).

In the new diagram, I have detailed more the interaction between GnuPG, OpenSSH and their agents, simply because that situation is quite complex and even I strained to get it right: GnuPG never speaks directly with either of the SCD implementations: there is always another process, gpg-agent that interfaces them with GnuPG proper, and it is this agent to provide support for OpenSSH as well. The distinction is fundamental to show off that it is quite possible to have the PKCS#11-compatible SCD implementation provide keys for OpenSSH, even though the original ssh-agent (as well as ssh itself) have support for the PKCS#11 interface. And also, the original scdaemon implementation can, in very few cases, speak directly with the USB device via CCID.

I have decided to extend the diagram to incorporate the TPM engine for OpenSSL while at it, making it much more explicit that there is a plugin interface between OpenSSL and PKCS#11. This engine access trousers directly, without going trhough OpenCryptoki.

Speaking about OpenCryptoki, of which I’ll try to write about tomorrow, I decided to expose its internals a bit more than I have done for the rest of the packages for now. Mostly because it’ll make it much easier tomorrow to explain how it works, if I split it out this way. In particular, though, I’d like to note that it is the only component that does not expose a bridge between a daemon process and the applications using it; instead it uses an external daemon to regulate access to the devices, and then users in-process plugin-based communication to abstract access to different source of secure key storage.

OpenCT could use a similar split up, but since I’m not going to write about it for now, I don’t think I’ll work more on this. At any rate, I’m very satisfied with the new diagram. It has more details, and is thus more complex, but it also makes it possible to follow more tightly the interaction between various software, and why it is always so difficult to set up smartcard-based authentication (and hey, I still haven’t added PAM to the mix!)

Smartcards again

People seem to know by now that I have a particular passion for the security devices called smartcards. I’m not sure why myself, to be honest, but a few years ago I decided to look more into this, and nowadays I have three smartcard readers at home connected to the three main computers I use, and I use a FSFe card to store my GnuPG keys and to login to local and remote SSH services.

In Gentoo, unfortunately, most of the smartcard-related software has been vastly ignored for years, or was and still is only considered for the small use cases of developers and users, rather than in the general picture of it all. I have been trying to improve the situation ever since I first experimented with token-based login over one year and a half ago, but even my results are not really good.

The last hard work I did on the subject has been directed toward pcsc-lite improvements which brought me to hack at the code to improve support for two of the three devices I have here: the blutronics bludrive II CCID – which has a firmware quirk, requiring to look up the CCID description in the “wrong place” – and a Broadcom BCM5880 security device that provides dual-interface access to standard smartcards and for contact-less cards as well — I have to thank my trip to London two years ago for having a RFID card available at home to try it out!

Since my personal smartcard setup has been mostly complete and working fine for a while now, I wasn’t planning on working hard on anything in particular for a while, unless, like OpenCryptoki a couple of months ago, my job required me to. On the other hand, after my complaining about stable testing from last week, I started wondering if I couldn’t leverage the work I’ve been doing on OpenCryptoki to allow an easy way to test PKCS#11 software for people without the required hardware devices. Between that and a messed-up bump of OpenSC (0.12.0) in tree, I have been looking hard at the situation again.

Before moving on to describe the recent developments on the topic, though, I’d like to give an insight on why you cannot blame it on anyone in particular if the whole handling of smartcards in Gentoo. The following UML diagram is a schematic, vastly simplified component view of the software (and, very selectively, hardware) involved in smartcard access:

In this diagram, the deep-green interfaces (circles) are those that are standardized by multiple organisations:

CCID is defined by the USB Forum;
CT-API is defined by a number of German organisations;
PC/SC is specified by its own workgroup which also defines the IFD interface;
PKCS#11 is defined by RSA.

The red components are implement as long-running services (daemons) on your Linux (or other Unix) system, the white ones are hardware devices, the blue ones are software libraries and finally the green ones are the applications the users use directly! Almost each one of those components is a standalone package (only package split in two components is GnuPG, and that’s just because Alon’s alternative SCD implementation makes it necessary to explicit the interface providers/consumers there.

This whole complexity not only makes it very difficult for distributions to manage software correctly, but also introduces a number of sensitive points of contacts between the software components, much more than one would like to have in a security-sensitive context such as Smartcards handling. Sometimes I wonder if they are really secure at all.

Back to what I have been doing in Gentoo, though. My first desire was to leverage The tpm-emulator and OpenCryptoki combo to allow arch testers to test PKCS#11 packages, such as pam_pkcs11 and pam_p11 (both of which are not part of the component diagram above by choice: to add those to the diagram, I would have had to add another indirection layer – libpam – to reach an user-accessible application like login) without the need of rare, and expensive, hardware devices. I’ve been working on OpenCryptoki’s ebuild and build system for a while, rewriting its build system and doing other general improvements — unfortunately it seems to me like it still doesn’t work as it is supposed to. I thought it could have been a problem with the software token emulation implementation, so I thought it might have been better to use the emulated TPM device, but even that method is not viable: even the latest version of the package does not seem to build properly against the current 2.6.38 Linux version, let alone the ancient version we have in the tree right now. I have a possibly-working ebuild for the 0.7 series (which uses cmake as basic build system), but since I can’t get the module to build, I haven’t committed it yet. This is likely one good candidate for the Character Device in UserSpace (CUSE) interfaces.

With the emulator being unbuildable, and the software-emulated token seemingly not working, using OpenCryptoki was thus slated for later review. I then switched my focus from that to OpenSC: version 0.12.0 was a major change, but in Gentoo it seems to have been bumped without proper consideration: for instance, the ebuild was committed with an optional pcsc-lite support, but without switches for any other alternative interface, and without any more support for the OpenCT interface that for some devices – including the iKey 3000 device that Gilles provided me with – is the only viable solution. Thanks to Alon (who’s a former Gentoo developer and an upstream developer for OpenCT/OpenSC), I was able to fix this up, and now OpenSC should be properly working in Gentoo — what is not currently implemented is support for non-OpenCT implementations of the CT-API interface; since I don’t know of other software that implements it that are available in Portage; if you know any of those, let me know and I’ll see to add support.

Now, for whatever reason, last time I worked on this, I ended up using pcsc-lite as my main hardware access provider – possibly because it is the easiest way to set it up for GnuPG and OpenPGP – and I didn’t want to throw it off right now, especially since I have a relatively good relationship with Ludovic (upstream) and I had already spent time fixing support for two of my three readers, as I said before. Thankfully, as the diagram suggests, OpenCT not only provides a CT-API interface, but also an IFD one, that can be used with pcsc-lite, providing a layered access to OpenCT-supported readers, including the ikey3k that I have here. Support for that in Gentoo, though, was not really sufficient: OpenCT didn’t install a bundle file for pcscd to discover, and the recent changes to pcscd to run without privileges disallowed the service from accessing the OpenCT sockets — I wouldn’t mind at some point moving all of the daemons to run under the same privileges, but that might not be so good an idea, and definitely not an easy one: while I can easily change the user and group settings that pcscd runs through – thanks to the Gentoo deviation I set the privileges just once, in the pcsc-lite udev rules file – it would probably require a bit of work to make sure that OpenCT and the other smartcard-enabled services didn’t step over each other’s toes. In the ~arch version of the two packages these issues are all solved, and indeed I can access the ikey3k device with pcsc_scan just fine, and from OpenSC as well.

I am unfortunately quite far from making use of the keys stored on the PKCS#11 devices in any other software than the PAM modules I have already written about. Alon’s alternative SCD implementation should make it possible to use any PKCS#11-compatible device (token or smartcard) to handle signatures for GnuPG and keys for SSH. What I’d be interested in, though, would be providing PKCS#11 interface to the OpenPGP card I have already, so to be able to mix devices. This should have been possible with OpenSC, as it implements an interface for openpgp applications and should expose it with PKCS#11 compatibility; reality, though, tends to disagree; I’m not sure whether it is simply a bug in the current code, or OpenPGPv2 cards not being supported by the project. I don’t think I’ll have enough time to work on that code anytime soon.

Alon suggested an alternative approach, by using “Scute’:http://www.scute.org/ — a project that aims at adding PKCS#11 interfaces to OpenPGP cards to be usable with Mozilla products. Unfortunately a quick check shows that the package does not build with the current version of its dependencies. And this is another task that would require me more time than I have, as I ”noted before“:https://flameeyes.blog/2011/04/storing-packing-and-disposing-of and thus will be simply slated for an undefined ”later”.

Supporting hardware device drivers

Today was a long, long day; due to some security issues with pcsc-lite, ccid and opensc, I had to kink out a few more issues with pcsc-lite, not only because I had to workaround upstream’s decisions that focused on fixing the issues with binary distributions (read: Debian), but also because the previous stable was 1.6.1, and the micro release after that (1.6.2) broke API enough to require patching a few reverse dependencies to work out properly.

Unfortunately, of the two class of issues, the one that might sound nastier (API break on minor bump) is actually the simplest to deal with, as you just need to compile the packages against latest to make sure it builds; while on the other hand, to test the udev changes, you have to check whether the reader is detected at all. This goes further, as there are a few possible problems when mixing different libusb versions between the driver and the actual pcsc-lite handler.

Unfortunately, while a theoretical inspection tells me that some of them should work, and a few of them won’t really work anytime soon, I’m pretty much out of options. Even for packages that Ludovic maintains himself, the sync between releases leaves a lot to be desired; for others such as the Athena drivers, there is really no way to tell whether they work at all or not.

The main issue here is that a lot of those drivers, like most other packages that deal with hardware devices, is that they are usually added by a developer who had use for them, mainly by having the device at hand, but then over time, either the device was obsoleted, or the developer left, and the package has been “maintained” by people who pretend to care enough to bump it around, but never even test or check what it installs.

The main point here is that for hardware-specific packages, we should really have a way to contact who can actually tell us if it works or not; the obvious way to solve this is by ensuring that some developer has access to the hardware (I do have CCID readers, and I’ve contacted Athena today to see if they can give me the means to test their drivers on Gentoo and keep them up to date), but that’s not always possible; either because not all of us will have eternal interest on the devices, or because the use of such device requires an infrastructure they just can’t afford to deal with.

So what’s my suggestion to solve this problem in a more manageable way? Well, actually an obvious one: proxy mantainership, at a slightly different degree than usual. Usually you have a proxied maintainer sending the committer, who vouches for the general quality of the ebuild and support files, but doesn’t go much into the details of working out how the software works or how to build it. When you actually need the device, though, you mightw ant to have a co-maintainer that can actually tell you whether it works and that can debug and kink out mistakes for you, even if you are doing the whole ebuild work; this basically means that it’s the kind of proxy maintainer that doesn’t need to know the first thing about ebuilds at all, beside being able to install it with the right options.

So if you own a device, and you know that its software is in Gentoo but is not currently actively maintained, please find a developer you’re acquainted with, and become the proxy maintainer, so that the package will actually work for everyone else!

pcsc-lite and the Gentoo diversion

You probably all know that I’m not really keen on diverging Gentoo from other distributions as long as it’s feasible, although I’m also always considering the idea of giving an extra edge to our distribution. Today, though, is one of the days when I have to implement something differently in Gentoo to have it working internally.

Today, Ludovic Rousseau released a new pcsc-lite version that is designed to improve autostart and increase safety and security by replacing a setuid-root with a setgit-pcscd. Together with that, a new ccid wrapper that sets the permission on USB devices via UDEV was released.

Now, while this looks all good stuff that improves user experience, this is mostly designed to solve issues with binary distributions — most likely, Ubuntu and derived. Autostart is mostly designed to avoid using a pcscd system service; in Gentoo that’s not much of a problem because it’s the user’s choice to start or not a init script, but on other distributions as soon as you install the package, the init script is scheduled to start. Once again, that’s not much of a problem when you install a server package, as that’s the whole point of it, but the pcscd service has to be bundled with the client library — and the client library is decided at build-time, so likely enabled for many packages, in those distributions. Again these aren’t enough of a concern for us, thanks to our customisable design.

On the other hand, the new design is troublesome for us: the daemons are started with the privileges of the current user, but access to the pcscd group; that would be okay if it wasn’t that it needs to create files in the /var/run/pcscd directory, which we cannot simply create in the ebuild – as /var/run could be on a tmpfs instance – and cannot simply be re-created by pcscd; it worked before because as setuid root it had all the privileges to do so. Ludovic suggested to create a reduced init script whose only task is to create the directory at startup, but at that point, why reducing to simply creating the directory?

The end result is as follows: the init script is updated, it creates the directory, alright, but now it executes the pcscd process under privileges of nobody/pcscd, rather than root, tightening security a little bit. More importantly, thanks to the fact that USB decices (and other hotpluggable devices) are handled through udev permissions, I’ve also created an extra rules file that hotplugs the service if a new device is added to the pcscd group, which gives a slightly better usability to Gentoo than before.

Unfortunately, this complicates the matter further, as versions of ccid and pcsc-lite need to go hand in hand, stabling them is a PITA; the fact that ifd-gempc is also not fixed yet really don’t make it any nicer. On the other hand, the presence of this now Gentoo-specific hotplug path through UDEV also mean that we could finally drop the HAL support in this ebuild, as that was supposed to provide the generic hotplug mean before.

I hope this situation will turn out good for everybody; if anything seems to be amiss, don’t hesitate to open a bug or tell me directly, and I’ll look into it.

In the land of smartcards

Even though I did post that I wanted to get onto hardware signatures I ended up getting an USB smartcard reader for a job that requires me to deal with some kind of smartcards; I cannot go much further on the matter right now though, so I’ll skip over most of the notes here.

Now, since I got the reader, but not yet most of the specifics I need to actually go on with the job, I’ve been playing with actually getting the reader to work with my system. Interestingly enough, as usual, the first problem is very Gentoo-specific: the init script does not work properly, and I’m now working on fixing that up.

But then the problem is to actually find a smart card to test with; in my haste I forgot about getting at least one or two smartcards to play with when I ordered the device, and now it’d be stupidly expensive to order them. Of course I’ll go around this time and get myself the Italian electronic ID card (CIE), but even that does not come cheap (€25, and a full morning wasted), and I cannot just do that right now.

So I went around to see what I had at home with a smartcard chip, after discarding my old, expired MasterCard (even though I thought about it before, I was warned against trying that), I decided to try with a GSM SIM card, which I had laying around (I had to get a new one to switch my current phone plan to a business subscriber plan; before I was using a consumer pre-paid plan).

Now, although I was able to test that the reader detects and initialises the card correctly (although it is not in the pcsc-tools database!), I wanted to see if it was actually possible to access it fully; luckily the page of a Gentoo user sent me to some software, written by an Italian programmer, that should do just that: monosim which, as you’d expect, is written in C# and Mono, which is good given I’m currently doing the same for another customer of mine.

Unfortunately, it seems like the mono problem comes up again: upstream never considered the fact that the libpcsclite.so ABI changes between different architectures, even on the same operating system. Not that I find that a good idea in general, since I always try to stick with properly-sized parameters (thanks stdint.h), but it happens, and we should get ready to actually resolve the problems when they appear.

Now, I really don’t even want to get started with all the mess that RMS have uncovered lately; just like I did a few years back, I replace the idealistic problems from Stallman with technical limitations, see for instance my post about “the java crap” (which – by the way – hasn’t finished being a problem, outlasting the idealistic problems).

And I’m still waiting for Berkeley DB to finish its testsuite, after more than twelve (12!) hours, on an eight core system, with parallel processes (I get five TCL processes to hog up the same amount of cores at almost any time). I don’t even want to think how long it would take on a single-core system. Once that’s done, I can turn the system down for some extraordinary maintenance.