As I have announced before I ordered two EntropyKey (one for Yamato so I can test it, and one for the router to put it into production). They arrived today, so I went on and packaged the ekeyd software (the daemon that takes care of feeding the entropy data to the kernel), which is now in portage as app-crypt/ekeyd.
There are though a few notes on both the package and the packaging procedure that I’d like to write about, for posterity.
Firstly, I really don’t see it as a really good move to make use of LUA in such a project; this is both because it looks like overkill to me, and because LUA itself isn’t really extremely standardised between distributions. In Gentoo, additionally, it’s using the wrong path for the compiled extensions, and is thus not really multilib-safe (although it’s debatable how useful multilib is getting, but that’s beside the point for now).
Another problem is, the software not only uses the base LUA code, but also needs the luasocket extension. And not even a vanilla luasocket, because it needs Unix socket support, and that is not built by default by the source package; I had to patch the sources to force building and installing it.
Beside these two problems, and the fact that the Makefile isn’t really extremely straightforward (and I needed to hack it a bit around to avoid -Werror and gzipping of man pages (Portage takes care of that), packaging wasn’t that much of a problem; the code seems clean and with the exception of some format warnings (reason why -Werror would have been a problem), no other problem was found (the package uses -fno-strict-aliasing though, which means that some optimisations will be discarded, too bad.
For what concerns the use of the package, the current ebuild in Portage is good enough for use, I’m using it myself, but it has some things that are still incomplete. For instance, it currently does not check for the Linux kernel options for CDC (and contextually I should probably keep a table of kernels to warn about — Linux 2.6.31 will not work for instance, out of the box, because of a bug in the CDC driver), and the userland USB daemon lacks an init script (which I would probably make much easier to use than the actual daemon: the daemon wants to know the USB bus position of the key, since I don’t like to rely on that I’d rather make use of lsusb or some other method to get the position from the ID pair and the serial of the key itself).
I am also pondering about moving the two daemons in /usr/libexec to avoid polluting root’s path with daemon commands (since they should only be started by the init script).
So as you might guess, there’s going to be a r1 version probably even today, depends on how much time I have free (I have lots of stuff to do, sigh).