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).
La prossima volta fammi un fischio, me ne sarebbe servita qualcuna e avremmo potuto fare un pacco da 10 🙂
It would be cool if you could mention a few experience reports on how they key improved perofrmance?
Firstly, Lua is not an acronym :)Secondly, we used Lua because it is a fast, lightweight, simple language that provides security benefits as well as ease of development. Lua itself is more widespread than you might think, and most distributions have it packaged, and for the platforms that don’t that we support, we provide packages.Debian/Ubuntu and OpenBSD seems to be the only platform that builds LuaSocket with the switch turned on for UDS. I have no idea why this is; I suspect careless packaging.I don’t understand what you mean by compiled extensions and multilib; but it does again sound like careless packaging. (Debian does appear to lead the way, here.)If our code isn’t -Werror clean, please report a bug.As for -fno-strict-aliasing, there were some difficult-to-fix aliasing issues that we didn’t have time to fix. Patches welcome.We made a mistake in assuming Linux’s CDC driver was good 🙂 The CDC driver, if it is compatible, does provide better performance than the userland one. We have not had a chance to compile a full list of which kernels have bugs that mean the CDC driver is a no-go. At the moment, the documentation on our website covers this. If in doubt, use the userland driver.The userland driver does not require an init script; it is launched by udev directly on plug events. This also solves your problem with knowing the USB device’s location. You might want to take a peek at 60-UDEKEY01-UDS.rules and ekeyd-udev in the doc directory of the tarball. Perhaps these should be moved to a more sensibly-named place :)If you have any other troubles, or anybody else has any other questions, you can drop me an email from the address at the Entropy Key website.
Eh, Lua, LUA, lately I capitalize everything just in case, but thanks, it’s handy to know.Oh I don’t doubt that Lua is widespread, and I probably would prefer seeing more things using Lua rather than custom scripting languages, but still it sounded odd to me at first. For what concerns Luasocket, Debian/Ubuntu and OpenBSD are probably just packaging luasocket “vanilla”; as I said to enable UDS I had to patch the package before building.The multilib problem is Gentoo-specific, and yes it’s “careless packaging” (or rather lack of proper QA test of the package); nothing major, just means I have to fix or get it fixed either way.Yes I noticed about the kernel CDC stuff, 2.6.31 with the patch (from the bug you link) seems to be fine, I “asked for it to be added to the Gentoo patchset”:http://bugs.gentoo.org/show… (and it’ll be on the next revision). It seems to be working fine here with this setup (this is why I got two keys, the one that’s going to be in production is not going to be experiment with ;)).And for some reason I thought the UDS was something for Ubuntu, my udev skills failed me there 😉 I’ll fix this in a r2 ebuild, thanks!
No, I meant Debian/Ubuntu and OpenBSD ship LuaSockets with UDS enabled. I’ve emailed the developer of the library to ask if he can make it easier for packagers to ship it with it on.(Under RedHat, we simply provide replacement LuaSocket packages.)
Gentoo as well then ;)But yes, it’d be nice if usptream luasocket fixed their makefile to just have a switch to enable or disable it depending on the OS.Anyway I just pushed a new ebuild, r2, with the fixes you pointed at, and a few more: * the udev rules for UDS are installed when the usb USE flag is enabled; * the ulusbd script is dropped for Linux systems, but it’s still present: I moved from using /sys to using lsusb (and a chain of processing), so that it works on FreeBSD and other OSes for instance (yes we do support them); * the CDC driver is checked for in the kernel; * warnings are added about CDC and a link is posted to your compatibility table.
I have to correct myself: I found another bug in cdc_acm, it works _as long as I don’t unplug and re-plug the key, otherwise it fails badly.Works fine with ulusbd though, so I’ll move to that on the router (I just put it in production) as soon as I re-do the rootfs image.
Cool. Great news that you got it all working 🙂