Sat, 16 May 2009
Belpic 3.5.2 has been released.
... and this time, with the source. Finally; it's been about a year since 3.5.0 came out without any source.
That's not to say it's going to be in the archive tomorrow; they changed the build system (again), and the source has been overhauled to such an extent that it basically isn't even the same software anymore. I'll have to re-learn everything, make sure it builds properly, and hope to do so by the time squeeze releases.
Yes, I realize that squeeze is still far away from release. Sigh.
Perhaps this is a good project for debcamp...
Sun, 02 Mar 2008
eIDconfig-belgium
Someone over at Novell wrote an application to enable eID in various applications with a simple click: you can enable web authentication in firefox, and email signing in Thunderbird and Evolution. It also does stuff which I didn't even know was possible under Linux—enabling eID card use under OpenOffice.org.
So I'm now a bit in dubio as to what I should do with this. I have an open bug report against libbeidlibopensc2 that claims the mozilla/firefox plugin should be automatically registered when you install the package, rather than having to go through a bit of javascript in some HTML file, and I kindof agree with that. I could analyze the C# code to see how the Novell people do it, translate that to C (since C# doesn't work on every architecture Debian supports, and besides I don't want to depend on yet another huge list of dependencies after wxWidgets and Qt), and call the relevant code from postinst to enable the relevant plugins system-wide. OTOH, allowing every user to make the choice for themselves, could be a good idea as well. Then again, that's not really the Debian way (if installed, it should just work). Then again, I don't think that enabling these plugins system-wide allows one to still disable it on a per-user basis.
Guess I'll have to give it some thought—other people's insights are appreciated.
Fri, 02 Nov 2007
Beid updates
There've been some posts on Planet Grep about using the Belgian electronic ID card in Ubuntu, recently. As the one who's responsible for making that possible, I felt I had to comment.
First, yes, it's possible to do crypto stuff with plain OpenSC rather than the belpic-patched versions; in fact, the tools required to sign plain text files aren't shipped anymore as part of belpic since (I believe) version 2.5.9, which is currently in Debian. However, if you're going to write your own software that somehow uses the eID, I strongly recommend you use the beid-patched versions, since they have support for a feature of which I can't remember the name currently but which means that you need to send your PIN to the card on every signature operation; plain OpenSC is not aware of this possiblity, so does not have support for it, may end up in a confused state when the card refuses to sign, and you may end up locking your card if you keep going on. You have been warned.
Second, there is a README.Debian file in libbeidlibopensc2 which explains some of the idiosynchracies in the packaging, and tells you which packages you need and which ones you don't. If you're interested in using the eID, I suggest you read it.
Finally, I'm currently working on packages of 2.6.0, which was released on 2007-08-30. They're mostly ready; I have a rather large changelog currently and a two-item TODO list—one of which reads "test&upload"; if all goes well, I should be able to upload them this weekend. Occasionally, this upload includes a small patch that was communicated to me through some mandriva developer which will make one of the aforementioned idiosynchracies—the fact that you have to install the -dev packages if you want to use the mozilla plugin—obsolete.
Fri, 06 Jul 2007
Beid issues: survey
I've been receiving a number of bugreports, both formal bugreports through the BTS and just people contacting me through regular mail or otherwise, about the packages for the Belgian Electronic ID card that I maintain for Debian. I think I'm starting to see a pattern in the bugs, but I'd like to be sure; and in order to be sure, I'd like for people who use beid on Linux to please send me the following information:
- Does it work for you? If not, does nothing work, or can you use some of the eID functionality? E.g., it might be that you can get the 'beidgui' application to start and do useful stuff, but that the firefox plugin doesn't work.
- Are you using Debian (or a derivative, like Ubuntu)? If not, what distribution are you using, and do you use a package or did you compile from source?
- What chipset does your smart card reader have? Does your reader use the PC/SC API, or do you use OpenSC? (note: this is a change that I made to the beid packages; the official government source does not contain OpenSC support, and I suppose neither do packages for other distributions)
- What processor do you have? (powerpc, amd64/em64t, i386-based, m68k, ...?)
I'd appreciate it if people willing to help me out could send me an email with their answers to the above at wouter+beid@grep.be. Thanks.
The pattern that I'm seeing currently is that people using the ACR38u chipset (as in the eID cardreaders sold by Zetes and the government) on amd64- or em64t-based machines cannot get it to work. What I'd like to find out is whether it works on other 64bit architectures, and/or whether it is acr38u-specific.
Of course, I'm not doing this on a for-pay basis (I 'simply' maintain the Debian packages), so there's no guarantees of me fixing these issues here.
Your cooperation is greatly appreciated.
Sun, 15 Apr 2007
Belgian eID proxy code
I was recently
(at FOSDEM) made aware of the fact that apart
from the client-side software, Zetes also provides some server-side
software to allow one to verify electronic ID card certificates on an
HTTP server. I didn't know about that, since nobody ever told me about
it; and none of the eID sites that I know of mention it, either. So
today I had a first look at the code to see what I'd need to do to
properly package it.
The code does contain a few WTFs, though.
- if (!r->proxyreq || !r->filename || strncmp(r->filename, "proxy:", 6) != 0)
+ if (!r->proxyreq)
+ return DECLINED;
+
+ if (!r->filename)
+ return DECLINED;
+
+ if (strncmp(r->filename, "proxy:", 6) != 0)
return DECLINED;
This one is especially silly if you know that the above is the only change to mod_proxy.c.
They do extensive changes to apache's mod_ssl, since that is where most of the needed work is done. The changes include the following stuff:
#ifndef BOOL
-#define BOOL unsigned int
+#define BOOL int
#endif
It's a boolean. By definition, that needs to keep only 2 values. The ability to set it to negative values doesn't matter.
But, well; the above two could be explained by compilers having strange ideas about what should be warned about. So let's ignore those. The code should be sane then, right?
Well, almost.
--- httpd-2.0.54/modules/ssl/mod_ssl.h 2005-02-04 21:21:18.000000000 +0100
+++ httpd-2.0.54-beid-proxy/modules/ssl/mod_ssl.h 2007-04-15 13:45:27.0000
00000 +0200
@@ -74,7 +74,7 @@
#include "apr_global_mutex.h"
#include "apr_optional.h"
-#define MOD_SSL_VERSION AP_SERVER_BASEREVISION
+#define MOD_SSL_VERSION AP_SERVER_BASEREVISION "+OCSP (1.0.8)"
#ifdef HAVE_SSLC
@@ -152,7 +152,7 @@
That's okay, sure? If you change mod_ssl to include OCSP support, you may want to change its version number to reflect that? Yes, indeed. But if you set the version number like above, and spread the rest of the mod_ssl code with patches like...
+#ifndef NOOCSP
(...)
+#endif
...and...
+ifndef NO_OCSP
(...)
+#endif
... then my guess is something's wrong with your processes.
Anyway. The modified SSL code for apache will be coming to a Debian mirror near you some time. But not soon.
Tue, 03 Oct 2006
Belpic 2.5.9-5
Or, beid 2.5.9-5
Which I uploaded today to Debian Unstable (and to backports.org as 2.5.9-5~bpo1). It contains the fix for #385735, which is filed in ubuntu as their bug 63632. I was going to fix it "soon" (since I have lots of other urgent things to take care of), but then it was pointed out that Ubuntu expects to release edgy near the end of this month, and that they'd like to have this bug fixed there.
When I looked at it on the train, I figured out that I had apparently already fixed the damn bug, just forgot to test and upload. Which is done now, after only half an hour (or so) of work. Whee.
Still TODO: fix #380275. But that's less urgent, so not for today.
Tue, 05 Sep 2006
Belpic 2.5.9-4~bpo1
Or, BEID of the same version. Oh well.
It took me a while, but I finally managed to jump through all the hoops[1] required by backports.org correctly and in the right order for the package of the above version to appear there. So if you're running sarge, have an electronic ID card and a smartcard reader, and want to see what the government knows about you, then go ahead and install them. More info on how that works can be found on the backports.org website.
There are two known issues as of now: first, you may get wrong root certificate errors; second, you need to install all packages from the belpic source package, or some things may fail. I intend to properly fix these two bugs Real Soon Now(TM), but I'm having issues reproducing the first one and am trying to wrap my head around being policy-compliant and produce working packages at the same time, which is required to fix the second one. It's slightly ugly; believe me, you don't want to hear the details.
Speaking of ugly, SCons is not ugly. It's downright hideous. I'll have autotools any day.
If you're not running sarge but are using Ubuntu 6.06 'Dapper Drake', then you will need different backports. Luc Stroobant was kind enough to provide them; use deb http://www.stroobant.be/eid ./ in your sources.list to get them.
[1] they are not many, but I managed to break my upload three times or so before it actually worked. And since I don't know about any status page or so, I needed to ask people every time—which I don't want to overdo, so I give them a while before investigating. Next time I probably won't...
Wed, 02 Aug 2006
Interesting things to do with an electronic ID card and a cardreader
So, now that I finally feel that belpic in Debian is in working order (in unstable), let's talk about the interesting things one can do with it. You have an eID, run Debian, just bought yourself a cardreader, and feel "now what"? This is the blog post for you ;-)
Note that there are still some rough edges; but I still have time to fix those before etch releases, so that's not much of an issue.
First, you need some support packages. If you bought a cardreader
from Zetes or got one from the Government somehow, then you have an
ACR38 reader and you need a hardware support package to be able to use
it; the package in question is called libacr38u
.
Obviously you will also need the belpic packages. For now, just install all of them—there still appears to be a dependency issue which I will need to fix; I'll announce on this blog when that has been done. Just run
aptitude install $(apt-cache showsrc belpic|sed -e '/^Binary/!d;s/^Binary: //;s/,//g')
and you will install them. I uploaded these packages to backports.org, too, where they'll hopefully show up some time soon (the current packages are still at 2.3.13 for some weird reason). This will give you:
- beidgui
- a graphical application that will allow you to view the data on the card, and to change your PIN code (as long as you still know your current PIN code and don't need to unblock it with the PUK; for the latter, you need to go to your local town or city or district hall).
- beid-pkcs11-tool
- a command-line tool that will allow you to change your pin and do some other interesting things. Note that while this is a command-line tool, you still need a GUI environment to be able to run it; there are cases where the libbeidlibopensc2 library will open a dialog window to ask you for your pin, without going through the application.
- beid-tool
- a command-line tool with not much options; it doesn't allow for much more than to test whether your installation works.
- beidcrld
- a daemon that will update the CRLs (Certificate Revocation Lists) when there is a network connection, so that you can verify the validity of the card in your reader. If you have a permanent Internet connection, there is also OCSP (Online Certificate something Protocol) which will verify the validity of your certificates against an online server, and which the preferred way to do this. Future versions of the belpic packages will have a /etc/default/beid which will allow you to disable beidcrld.
- beidpcscd
- a daemon that is used if you need libpcsclite to talk to your cardreader. If you have an ACR38 cardreader, you need this. I personally have a different one, which uses openct, so I don't...
- a whole bunch of libraries
- However, only three are really interesting: libbeidlibopensc2, for low-level operations on the card (such as "read a file", "sign some data"; libbeid2, for high-level operations on the card (such as "read identity data", "read a picture"), and libbeidlibjni (JNI library, if you want to use the eID from Java). Libbeidlibopensc2 and libbeid2 are packaged separately; libbeidlibjni is packaged together with libbeid2 (though that might change in the future, not sure).
- Some files to support mozilla, firefox, and other browsers.
- The most interesting ones from a user point of view are /usr/share/beid/beid-pkcs11-register.html and /usr/share/beid/beid-pkcs11-unregister.html. Note that registering the module isn't enough to be able to use it; you will have to perform some additional steps which are outlined on eid.belgium.be, the government website about the eID.
Additionally, there is also OpenSC which you may want to install. The point there is that things like OpenSC's pkcs15-tool and pkcs15-crypt do not have a counterpart in the eID toolkit, so if you want that, you need to install it.
So, that's the software in the eID toolkit. But what can you do with it? There are a number of things. For starters, of course, there's the beidgui, which allows you to view, save, print out, and do other interesting things with data on a card. If you work on a place where you regularly need to work with eID data, this may just be the appliation for you.
If you have set up your browser to support the eID, you may want to go to mijndossier.rrn.fgov.be, a website set up so that everyone can view their own information in the Rijksregister. I'm sure there is a French version of that URL, but don't ask me—I don't know it.
You probably already know about tax-on-web, where you can do your tax application online.
It is possible to install a signing module into Mozilla Thunderbird, and to sign your emails using S/MIME and the eID card. This will give you a signed email which is legally binding; might be interesting for those of you out there interested in not having to use as much paper signatures. Details, again, on eid.belgium.be. The same is true for signing documents in OpenOffice.org. I haven't tried doing any of this myself yet, though.
Of course, you can sign any text file as well, using pkcs15-crypt from OpenSC, or extract the certificates on the card using pkcs15-tool. Just run them with the --help parameter to find out about their options.
And that's about it, I guess. More interesting links can be found on a a portal maintained by Danny 'godot' Decock on the eID.
Sun, 23 Jul 2006
Belpic: Success! :-)
Finally. For the first time ever, I've been able to log on to tax on web using my electronic ID card.
Too bad I've already filed my tax report on paper. Oh well.
If you live in Belgium, use Debian unstable, have an eID card and a reader, and haven't filed your tax report yet, this might be nice to do. I'll update the backports on backports.org any time soon, but they need some patches (gcc3 and gcc4 have some different ideas on what is well-formed C++ code, grmbl), so that's not for today; so if you need sarge backports, don't count on it just yet.
Wed, 12 Jul 2006
Belpic 2.5.9
Yesterday evening, I noticed that the 2.5 release of support software for the Belgian electronic ID card had come out earlier this week (on 2006-07-04, to be exact). I didn't know, nor notice. Sigh.
I knew this release was forthcoming; I had been working with some Zetes developers on the code a few days last month, and they had implemented a number of my suggestions. Always nice to have a working relationship with your upstream. They hadn't implemented everything I had pointed them to (mainly due to lack of time because of a deadline they were running up against), but my suggestions had at least avoided some serious bugs that would otherwise have been in the release. Great improvement over the 2.4 release, which couldn't even be built due to a serious SNAFU in the code.
But, now, this isn't happening anymore. The only thing is that Zetes isn't the one doing official releases of the Belpic code; that honour is left to FEDICT. And while Zetes happily talks to me, I can't seem to get anyone inside FEDICT to talk to me. I've sent them some emails in the past, asking them some questions, but I've never had any of them reply to me.
Like I said: Sigh.
Oh well. So yesterday, late at night, I found out that the new release was out, and I promptly updated my packages. Err, well, at least, I almost did so. I actually postponed it to today, since, well, it was late already. And it is again, now, with my packages almost being finished; I had to redo some bits since, somehow, I seem to have lost my work of last month. Grmbl.
Anyway. The packages seem ready now. When I get home, I'll test them just one more time, and then they'll be ready for upload. Whoo!
Thu, 11 May 2006
2.40: Bug found.
A long time ago, I reported about how I couldn't compile belpic 2.40 on Debian. At the time, I'd assumed it had something to do with my (mis)understanding of SCons, a make/automake/autoconf/... replacement written in python that upstream had migrated to.
As it turns out, that isn't the case.
Script started on do 11 mei 2006 11:28:01 CEST wouter@country:~/Desktop/bel-eid-nl-linux/_stap_2/src/pkcs11/src/include/opensc$ ls -l totaal 4 -rw-r--r-- 1 wouter wouter 0 2005-12-01 10:14 asn1.h -rw-r--r-- 1 wouter wouter 0 2005-12-01 10:14 cardctl.h -rw-r--r-- 1 wouter wouter 0 2005-12-01 10:14 emv.h -rw-r--r-- 1 wouter wouter 0 2005-12-01 10:14 errors.h -rw-r--r-- 1 wouter wouter 0 2005-12-01 10:14 log.h -rw-r--r-- 1 wouter wouter 0 2005-12-01 10:14 opensc.h -rw-r--r-- 1 wouter wouter 0 2005-12-01 10:14 pkcs11.h -rw-r--r-- 1 wouter wouter 0 2005-12-01 10:14 pkcs15.h -rw-r--r-- 1 wouter wouter 0 2005-12-01 10:14 pkcs15-init.h drwxr-xr-x 2 wouter wouter 4096 2005-12-01 10:14 ;34mrsaref -rw-r--r-- 1 wouter wouter 0 2005-12-01 10:14 scconf.h -rw-r--r-- 1 wouter wouter 0 2005-12-01 10:14 scdl.h -rw-r--r-- 1 wouter wouter 0 2005-12-01 10:14 scldap.h -rw-r--r-- 1 wouter wouter 0 2005-12-01 10:14 scrandom.h -rw-r--r-- 1 wouter wouter 0 2005-12-01 10:14 types.h wouter@country:~/Desktop/bel-eid-nl-linux/_stap_2/src/pkcs11/src/include/opensc$ Script done on do 11 mei 2006 11:28:05 CEST
AAAAARGh!
Wed, 07 Dec 2005
Belpic 2.40
When I had almost finished packaging belpic 2.3.13.full, I contacted upstream to notify them of this fact, also mentioning that I'd replaced their build system (which used simple makefiles with many bugs) with an autotools-based one. To which I got the reply that they'd already prepared a belpic 2.40 in the mean time (available at readers.eid.belgium.be), and that they'd switched to SCons as their build system in the mean time. Since I'd spent quite some time on 2.3.13.full already by that time, I decided to continue to prepare that package, and focus on 2.40 afterwards
Now of course I'm happy that they chose to use something different from plain buggy MakeFiles. I'm less happy that they chose something based on python, a language which I haven't liked, ever, and don't know much about either, but, well. That's their choice, right? I'm also less happy with the fact that it doesn't properly clean up after itself (requiring me to do ugly stuff in my debian/rules clean target), and that it doesn't work. Grmbl.
The build currently fails on a file that hasn't changed, because it can't find a symbol which is defined in a file in the same directory that hasn't changed, either. When I rerun the gcc call with the -save-temps argument and review the preprocessed source, I see that that include file is mentioned, but not included.
Something is clearly wrong here. Guess I'll have to start learning python... hrmpf.
If you care, belpic is the software required to read out the information and keys in a Belgian electronic ID card. Not of much use if you don't need to read Belgian ID cards, though :-)
Mon, 28 Nov 2005
Belpic Backports
My belpic backports have now been added to the backports.org pending directory, until the dak setup there is finished (at which point they'll be accepted into the 'real' bpo archive).
Oh, and Yes, you're right; sorry. So, for those not familiar with the thing, belpic is a little piece of software which was written by the Belgian Government in the context of the electronic id card project; it allows Belgian citizens to read out the information and X.509 keys on their ID card, so that they can use it to identify themselves, make signatures, and thusly do other generally interesting stuff, such as using the government's tax-on-web application.
Thu, 24 Nov 2005
Belpic for backports.org
I just uploaded a belpic that compiles on stable to my people.debian.org webspace, so that people using stable will be able to use belpic, too, and might be able to use their digital ID card to sign emails, or use the tax-on-web thingy of the Belgian government. The idea is to get this into backports.org, but I can't reach Norbert Tretkowski ATM, so it'll have to wait 'till he reads his mail.
One thing is weird, though. To be able to build belpic for unstable, I had to change some things like (unsigned char **) in the code to (const unsigned char **), or it wouldn't compile. Now that I try to compile it on stable, I apparently have to reverse those changes, or it won't compile. Probably some definitions of one (or more) of the build-dependencies changed. Not that it's a problem, of course, but it is silly.
On a slightly related note, Zetes N.V. (belpic's upstream) suggested I go ahead and maintain packages for them to put on the Government's website, too, so that people would be able to install it by downloading from belgium.be. This wouldn't just be the Debian packages, but also packages for other distributions (probably RPMs, then). Sounds like fun. This isn't at all official yet, but it might be some time from now.
