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.