This release features a complete rewrite of the server core. It is now able to scan for devices on the following buses:

• raw USB
• USB serial
• PCI
• PCMCIA

This release is based on the latest release of Gwenhywfar (1.99.0beta), so in order to use it you must update Gwenhywfar, too.

This release fixes some bugs in version 1.9.13beta which prevented AqHBCI from using DDV cards.

Please note that Libchipcard2 1.9.13beta and newer obsolete the AqHBCI plugins DDVCard and RSACard.

• added pseudo CTAPI driver which transparently allows CTAPI-based programs to use whatever reader Libchipcard2 supports
• added an OpenSC reader driver module which allows OpenSC to use Libchipcard2 instead of CTAPI or PC/SC
• added support for remote drivers (to be used by Gnumed in thin-client-networks)
• added a service for German medical cards (thus replacing the KVK daemon of Libchipcard1)
• many, many bugfixes

These pages have been created using the phantastic OpenOffice which also exported them as HTML ;-)

This driver allows every program with the ability to access CTAPI drivers to work with Libchipcard2.

This is done by telling the program that Libchipcard2 itself is such a driver. When ask for the driver file select /usr/lib/libchipcard2ctapi.so

I fixed a bug in the Cyberjack driver and added a feature expected for version 2.0.6. This is necessary to use the latest Libchipcard2 version.

Please replace version 2.0.5(mp) of the driver on your system with this one.

As soon as 2.0.6 is out you should use that version.

From now one the package Libchipcard2 contains the client and the server code.

This version contains some very important fixes. Interprocess communication is much faster now. For old Cyberjack readers you need the latest driver version (either my version - see above - or 2.0.6, as soon as it gets out).

I just fixed a bug in the Towitoko driver for serial readers concerning memory cards with a capacity of 16KB. Those cards do not work with the latest released driver.

I already informed Carlos Prados (the author of the driver) but he didn't answer so far. So I decided to offer my version on the download page.

The current CVS contains a merged version of Libchipcard2. Future releases will therefore only consist of a single package which contains both client and server code.

This will make it much easier for me to maintain Libchipcard2.

These are the last releases for this year.

• improved support for Cyberjack devices
• added autoconfig support for Kobil Standard Plus (USB) devices
• fixed many bugs
• uses the IPC cleanup code in Gwenhywfar, so now the server becomes usable in productive environments
• added FAQ

• added tool memcard2 (reads and writes raw data to/from memory cards)
• added tool kvkcard2 (reads data from a German medical card)
• added tool cardcommander2(allows to enter and execute chipcard APDU commands)
• added commands to chipcard-tool:
  • atr (waits for a card and shows the its ATR string)
  • check (makesthe server try to start all attached readers and monitors the progress).

I just added some important code to the server CVS module. This version should now work without problems with all cyberjack devices.

Here is some information about which driver to use with which Cyberjack reader.

How To Identify The Reader

Just use the following command to check for the version of your reader:

lsusb

This should deliver some lines of text saying something like this:

Bus xxx Device yyy: ID 0c4b:0100 (for old Cyberjacks or ecom)
Bus xxx Device yyy: ID 0c4b:0300 (for new Cyberjacks)


Ecom or old Cyberjacks

These devices use the USB serial converter. They work best with the old driver (version 1.x).

Please note that theoretically the new driver also supports old Cyberjack devices. However, sometimes it gets confused when it comes to detecting the correct /dev/ttyUSBx device, especially when other USB-serial devices are present.

New Cyberjacks

These readers use USB directly. Therefore the most recent driver (2.x) is needed.

• added support for new Reiner-SCT Cyberjack
• added autoconfig support for Kobil Kaan Pro USB readers
• started working on support for Omnikey readers
• completed notification framework
• added tool chipcard-tool
• whenever an USB reader is plugged in the driver/reader list is reloaded
• fixed some bugs

The current CVS version contains a notification framework. This allows clients to sign up for the reception of notification messages. These messages tell the interested client about which reader/driver/service has been started/is up/is down etc.

I also just started working on a KDE tool which monitors the state of the chipcard2 daemon (KChipcard2Mon). It will show a docked icon with the current status of the card readers.

• added support for STARCOS cards (as far as HBCI is concerned)
• added a tool to manipulate HBCI-related data on those cards
• fixed many internal bugs
• added Towitoko Chipdrive Micro USB to the list of autoconfigurable readers

• autoconfiguration of USB readers (Cyberjack, SCM)
• setup-tool for the server package, this allows for an easy setup of chipcard2-server
• added support for Towitoko Chipdrive Micro (serial)
• many bugfixes

The current CVS version of the server now has improved and portable autoconfiguration capabilities ;-)

This is acomplished by using libusb.

In theory autoconfiguration should now be portable across multiple POSIX system (amongst which are Linux, FreeBSD, NetBSD, OpenBSD, Darwin).

I will make a new release this weekend.

The current CVS version of the server now has autoconfiguration capabilities.

However, this only applies to systems running Linux 2.4.x (since /proc/bus/usb is used).

The following readers can now be detected and setup automagically:

• Reiner SCT Cyberjack
• Towitoko/SCM Chipdrive Pinpad

In theory all USB readers can be detected. But for this to work you need a description file (driver.xml) which tells Libchipcard2 which vendor/product id pairs belong to which reader and where to find lowlevel drivers.

Serial readers however will never be detected automatically since autoprobing serial ports could freeze your system (and maybe even damage hardware connected to serial ports).

The current CVS version of the server now has a test mode for every driver.

In this mode a driver does not contact a chipcard daemon but tries to connect a card reader directly.
This can be used as a replacement for the old Libchipcard tool readertest.

• added support for German medical cards
• added support for Orga readers
• fixed many bugs

I just released a plugin for the old OpenHBCI version used by GnuCash. This new plugin uses Libchipcard2.

If you want to use this new plugin with AqMoney or GnuCash you will have to install it and change all occurances of DDVCard in the configuration file ~/.openhbci by DDVCard2.

To change it back you simply need to revert these changes and deinstall the new plugin.

While watching the download count I realized that there are more downloads for the client package than there are for the server package. Well, unless you have another Chipcard2-Server you will need both packages in order to use a chipcard reader...

The server package is the one which manages your card readers while the client simply accesses the server to find inserted chipcards and to issue commands to the cards.

I just released the current CVS-version of libchipcard2.

What's new ?

• direct support for IFD drivers (lowlevel drivers written for PC/SC)
• unused readers are released
• each driver runs in its own process and thus is unable to block the chipcard server or other readers
• card/driver descriptions are now written in an XML-alike format. Tthe server handles card command formats, the client handles data formats (describing the file and data structure on a chip card)
• a new IPC (interprocess communication) model with security ranges from unsafe (without using any encryption) to very secure (with the need for valid SSL certificates) is used (introduced by LibGwenhywfar)
• secure pin verification with SCM (Towitoko Chipdrive Pinpad) readers is now supported

The current CVS version contains support for IFD drivers used for PC/SC ().

This allows Libchipcard to directly use drivers created for PC/SC (since most readers today ship with an IFD driver rather than with a CTAPI driver).

The current CVS version of Libchipcard2 now works with CTAPI drivers for Kobil and Cyberjack readers ;-)
Support for Towitoko readers will follow soon.
I also wrote a new DDVCard plugin for OpenHBCI2 which now uses Libchipcard2.
I'm using this plugin on my home system, so I have to be sure that it works the way it is supposed to (I can't afford to loose my HBCI card again).

Currently Libchipcard2 only supports processor cards and HBCI cards.

The next priority is to write a driver abstraction which is able to directly use IFD drivers (these are the drivers used by PC/SC) in order to get the SCM reader to work as well.

You can get the current CVS version of Libchipcard2 this way:

	  cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/libchipcard login
	  [press enter when asked for a password]
	  cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/libchipcard co chipcard2
	

1. chipcard2-server: The server module containing the new chipcardd2
2. chipcard2-client: The client module containing support for processor and HBCI cards

The current CVS version of Libchipcard2 now contains a new chipcard daemon. This new daemon starts a new process for every reader. After a given timeout the readers are released in order to make them useable with other programs which directly access them via CTAPI. This solves some of the problems reported with the old chipcard daemon.

I will hopefully release a first test version of Libchipcard2 this week.

The latest driver for the Towitoko Chipdrive Pinpad now has support for secure pin input via the builtin keypad.
However, since the implementation in that driver differs in a way incompatible to that used by other manufacturers (e.g. Kobil) Libchipcard is currently unable to use this functionality.
So for now you still have to disable the keypad with KCardSetup.

I just started programming the upcoming version of Libchipcard (1.0), and that version will have support for secure pin input with this driver.

This bug forces you to use incorrect USB port numbers with Reiner-SCT Cyberjack, i.e. if your reader is connected to USB0 you have to tell libchipcard that it is connected to USB1.

Well, the bug description contains the workaround, so this is not a severe bug. However, I guess I will have to make a new release in the next week or so.

Thanks to Nils Ohlmeier for fixing these bugs and submitting patches ;-)

This is the plan:

• moving the system layer and other basic stuff previously located within libchameleon into its own project ( http://sourceforge.net/projects/gwenhywfar) )
• make libchipcard use this library instead of the old chameleon stuff and add some new features (see older news below for a list of planned features)

After that I will be able to work on OpenHBCI again. The next generation of OpenHBCI is based on Gwenhywfar, so that project has to be finished before I can finish OpenHBCI.

Hi guys, please hold on, next week I will begin working on the next version of Libchipcard.

Well, first I will have to move the libchameleon stuff into its own project which is called Gwenhyfwar. This is a base library which has been used by Libchipcard and AqBackup for a long time, and which will be used by the next version of OpenHBCI.

BTW: Please note that I will not accept any HTML mails anymore! All HTML mails are moved to /dev/null because in the last few months I've been flooded with spam mails and I really got sick of it. And most of them are HTML.

It has been reported that using a Kobil B1S Professional card reader sometimes does not work with Libchipcard.

In that case you should verify that the firmware of the card reader has a recent version (version 1.04 does not work, while version 2.08 does).

You can download recent firmware versions from Kobil.

This is just a maintenance release. It fixes some minor bugs and typos and improves the debugging output.

Until September I have no time to create binary packages, so for now you are stuck to the tarball.
However, compiling libchipcard yourself is very easy (thanks to the autotools), so this should not be a problem.

The current version of OpenHBCI does work with this release, so it is safe to update libchipcard.
The update urgency is quite low, since the previous release is stable, too.

Libchipcard seems to be quite stable now, at least I did not hear about any complaints in the past.
So I will make a maintenance release (0.9.1) this week which will only have minor improvements.

Between that release and September of this year there will be no more work on Libchipcard, since I have to prepare for my Aerztliche Vorpruefung.

But I already have some Ideas for the next major release:

• maybe support for 2nd generation G&D RSA cards (hopefully)
• continue working on an RSA card tool
• make each CTAPI driver live in its own process. This will allow me to prematurely abort driver actions (in case the driver does not respond). It will even allow me to selectively shut down or reset a reader at runtime
• improved KChipCardControl: It will give you more information (statistical information, version info etc)
• improved KCardSetup (will have a new-driver-wizard)

Some more ideas (farther away)

• a fake-CTAPI which will allow tools which normally work with a CTAPI driver directly (like Moneyplex) to work with Libchipcard
• add Libchipcard support to OpenSSH or GnuPG (but I would need much help on this, I guess)
• ... and whatever ideas you come up with ;-)

• for the first three days I could not login (shell account down)
• for the same time I was unable to login to my CVS repository
• and now at least the last two days the Berlios WWW servers are down, so that nobody can reach my homepage or projectpage at Berlios.
  This sucks!

• libchameleon: The major operating system abstraction level library, which also includes some generic function groups which are often needed when developing programs/libraries
• ctservice: This is the IPC level used by Libchipcard since version 0.7. I never had to change it very much since I rewrote it for Libchipcard 0.7, now using C instead of C++

This has some big advantages for Libchipcard, too: While I'm working on AqBackup I'm improving these core parts, so in the end this will benefit the next version of Libchipcard (0.9.1) ;-)

The reason why I wrote my own backup system is simple and typical for all OpenSource developers:
I did not find an existing system which fullfills my needs in the way I want it:
I want to:

• have a dedicated server who will handle all backups from my local network
• have a revision controlled backup system (just like CVS), which allows me to store and (what's more important) to restore any version I submitted.
• specify the version I want to restore by a time: With AqBackup I can say: Give me that version of a file that existed on June 05, 01:00 am. Or even a full directory.
• backup some directories more often than others
• restore any directory to an other destination directory
• make full or differential backups
• let the backup server prepare CD images while he is idle
• have something I can easily write a KDE GUI for (console UI already exists)
• code something like this ;-)

AqBackup is hosted by Berlios (project page is http://aqbackup.berlios.de)

I hope someone else finds this project as usefull as I do ;-)

Unfortunately I don't have Redhat 9.0 (I have SuSE, Mandrake, Debian, Redhat8 and I don't want to add yet another system just for this single purpose of buidling packages).

However, I started a call for help on the mailinglist but nobody answered so far.

So as long as nobody feels the need to give back to the Open Source Community instead of taking only I will not be able to provide you with more packages than those I already have.

I finally released the new generation of libchipcard.

Please note that if you are using Libchipcard with OpenHBCI then you should probably wait until this weekend, because otherwise you would need to use the CVS version of OpenHBCI.

However, the next release of OpenHBCI is scheduled for this weekend, and that version will be adapted to the latest changes in Libchipcard.

• temporarily stop the chipcard daemon
• continue a previously stopped daemon
• shutdown the chipcard daemon
• force chipcardd to reload its configuration files

• all tools now ship with a German translation, and since gettext is used you can add translations for any other language yourself.
• the tool hbcicard is more informative when using the command info, now the ATR of the card is shown as well.
  This tool also has a new command called pinstatus. This command shows how many bad tries are allowed for PIN verification, and how many of them you already used.
• KMedicalCard now picks the correct card out of all currently loaded readers.
  This program has been improved internally, so that it now works more smoothly.
• Some major improvements on internal libraries, such as libchameleon and libservice.

• libchameleon, the operating system abstraction layer, is now split off Libchipcard, because I'm curently using it in other projects, too
• AQService, which was the Inter-Process-Communication Layer of LibChipcard, is now on its own as well.
  This part will be used in other projects, too.
  In addition, this will allow me to have each CTAPI driver in its own process, so that such a driver is no longer able to block other readers (some CTAPI drivers use to take a long time for some commands, and while those commands are in progress the current Libchipcard is blocked. This will change in the new version).
• chipcardd, will fade in the next generation. It will be replaced by aqserver, which is the daemon for AQService (described above). So from then on Libchipcard will only be a service provider to AQService.

What's New ?

Direct creation of CTCard and derived objects is no longer allowed. You must now use the new class CTCardTrader which waits for cards and returns a valid CTCard object if a card becomes available. This new class basically replaces the whole startWaitForCard et. al. stuff which started to become intransparent.

I included some very descriptive tutorials to show how this works. I will add support for the current version to the appropriate OpenHBCI plugins in order to make tis version usable with OpenHBCI.

The CTCard class is now much cleaner, some unnecessary methods of CTCard have been removed and some bugs have been discovered and fixed.

I also started to work on a windows version of the chipcardd. The tools and Libchipcard itself already work under Windows, but due to the Windows environment which is totally incompatible with Unix (->signals and other stuff are missing here) the chipcardd which was designed for POSIX systems is more or less useless under Windows.

I also started adding internationalization to the tools. Now all tools are shipped with a German translation.

• rsacard.cmd
• ctprocessorcard.cmd
• hbcicard.cmd

• adapted to latest changes in OpenSSL, which could cause Libchipcard to crash (OpenSSL decided to use some parts of an RSA key structure which previously weren't used)
• internationalisation for the tool HBCICard (complete German translation is now provided)
• some internal improvements
• some bugfixes
• improved KVKd, the daemon for German medical cards, designed to be used by GNUMed

• updated libtool from 1.4.2 to 1.4.3 to support Debian mips and mipsel architectures
• adapted to latest changes in OpenSSL

• added driver description file for Orga readers, now you can select that reader type directly within KCardSetup.
  Thanks to Sebastian Hilbert from GNUMed ;-)
• KVKd now beeps after handling a card (unless disabled)
• fixed some bugs in ctcard.cpp and readerserver.c

• WaitRequests now have an additional parameter, which tells the server, which part of the reader status has to change before the server sends a status change notification.
  This makes KVKd now work the way it was intended.
• KVKd now reads an inserted card only once, instead of reading the same card again and again.
• KVKd now uses the same logging mechanism the other tools use.
• KVKd (and other tools possibly as well) is now able to reconnect to the card daemon if for some reason the connection is broken

• SuSE Linux 8.0
• SuSE Linux 8.1
• Redhat Linux 8.0
• Mandrake Linux 9.0
• Debian Linux 3.0 (woody)
• FreeBSD 5.0-RELEASE (the KDE package maybe has to be installed using pkg_add option -f)

• Readertest:
  • now accepts parameter -n NAME to state the reader name. This is needed for testing PC/SC driven readers
• KCardSetup:
  • removed commands button (this is now chosen by KCardSetup itself, because in the past this setting has proven to be more confusing than of any help)
  • added a button that allows to import PC/SC driven readers. You don't have to do this by hand any more. Anyway, you only need this if you have a PC/SC driven reader which has a keypad or a display, though it doesn't hurt to use this even with other PC/SC driven readers.
  • adjusted to latest changes in tool readertest to allow testing of PC/SC driven readers as well
• KMedicalCard:
  • improved evaluation of error codes, improved loop which waits for a card to be inserted

• fixed a bug which might have caused chipcardd to crash
• fixed a typo in configure script
• if chipcardd has been started with option --exit-on-error and the daemon is disabled by the configuration file it will stop fully (and thus will not be restarted by a simple HUP signal. But anyway, using the option --exit-on-error is not really recommended, but it has been demanded by one packager so here it is).

• finished implementing unix domain socket transportlayer. If this layer type is used no encryption takes place, thus allowing even slower machines to perform in acceptable speed.
• improved config file handling: now you can additionally give the reader flags like this:
  "flags=keypad,display" instead of "flags=3"
  Please note that numerical values are deprecated, so for 0.9 they most likely won't be supported anymore.
• added driver descriptions. Now the translation of port names (e.g. "COM1") to port values (e.g. "0") for CTAPI drivers is no longer hardwired into Libchipcard. You can now add support for any CTAPI driver by just adding such a description file. Please have a look into the folder "data/drivers".
• removed driverType from find and wait requests. No application should depend on the way a reader is accessed.
• reader type is now given as a string to those requests. This allows the driver to lookup the port values even for readers not already known.
• please note that older clients will not work with version 0.8 daemons, because of changes in some messages.
• internally switched over to version 0.8
• added command line option "--exit-on-error" to chipcardd. Normally the supervising process simply suspends chipcardd if there was a setup error amd waits either for a HUP or CONT signal. With this option chipcardd will exit completely upon setup error.
• KCardSetup now reads the port names and reader types from the driver description files. This allows to add support for new drivers to KCardSetup without recompiling it.

• Libchipcard now supports Unix Domain Sockets (not with WIN32). This allow even older machines to perform reasonably, because this socket type removes the need for encryption. However, network connections are still encrypted for security reasons
• chipcardd is now smarter when respawning a crashed daemon, it doesn't eat the whole processor power anymore ;-)
• the supervising process is now more persuasive when when bringing down the daemon: If the daemon doesn't respond properly within a reasonable time it gets killed

• chipcardd now recognizes some more signals:
  • TSTP: Temporarily suspends the chipcardd thus allowing other programs like KCardSetup and readertest to access the readers directly
  • CONT: Resumes a previously suspended chipcardd and makes it reload its configuration
  • HUP: Forces the chipcardd to reload its configuration
  You can send a signal to chipcardd via this command (e.g. sending a CONT signal):
  killall -CONT chipcardd
• fixed a bug in IPCTransportLayerTCP which sometimes caused cardcommander to crash
• logging now logs the process id, too
• figured out how to securely verify a pin with a Reiner-SCT Cyberjack reader

• fixed some bugs in tool hbcicard
• added logging options to tool memcard
• fixed a bug in CTAPI handling code
• fixed some minor bugs in KCardSetup
• KCardSetup now checks whether there are command files in the given command path

• readertype "Other" is not handled correctly (actually it's unusable)
• chipcardd could crash if debugmode is "info" or higher due to a silly bug (grmpf)

• Debian woody (stable)
• Debian sid (unstable)

• SuSE 8.0
• SuSE 8.1
• Redhat 8.0
• Mandrake 9.0
• Debian Woody
• Debian Sid
• FreeBSD 4.6.2

• compiles under WIN32 out-of-the-box (using mingw32 plus msys)
• compiles and allows creating packages under FreeBSD 4.6.2
• further separation of libchameleon from the rest of libchipcard (thus allowing other projects to use libchameleon, too. I will need this in one of my planned projects)
• Fixed a bug in the server code which has been introduced with the separation of chameleon in version 0.7.2 (clients that died were not correctly unregistered, this led in some cases to inaccessability of a reader because of locks owned by dead clients).

• the tool hbcicard has a new command: keys. It shows which keys on a RSA card are in use.
• added manpages written by Thomas Viehmann for the tools geldkarte and hbcicard

• compile fixes for FreeBSD 4.6.2
• compile fixes and porting to WIN32
  The tools do work now, I didn't check the chipcardd, though. I don't know how I can start a background process under Windows, without having a console window for it :-(
  If someone could help me out in this matter ... ?
• Separated Chipcard stuff from the internal libraries. This allows using the IPC framework in other projects, too.
  Unfortunately I had to change the code numbers for the messages, so a 0.7.0 client will not work with a 0.7.1 daemon and vice versa.
  But that isn't much of a problem, since I will provide the same binaries for 0.7.1 I provided for 0.7.
• other minor cleanups/fixes

• LibChipCard has completely been rewritten, the core is now in C instead of C++. This makes it much leaner.
• the packages have been split into several subpackages:
  • libchipcard: The library itself
  • libchipcard-devel: Include headers etc for creating your own programs based on LibChipCard
  • libchipcard-tools: Mandatory chipcard daemon and other tools (memcard, hbcicard, geldkarte, German medical card daemon for GnuMed etc)
  • libchipcard-kde: Graphical KDE tools (KCardSetup, KPCSCSetup, KMedicalCard)
• added some new console tools:
  • cardcommander: A very (very) simple debugging tool (which is nonetheless quite usefull)
  • geldkarte: A tool which shows how much money is loaded on a German "Geldkarte"
  • readertest: An internal tool which allows KCardSetup to check a reader before writing the configuration file
• much improved documentation
  • added manpages for the chipcard daemon and the configurations files
  • added documented example configuration files
  • added German translations to all KDE tools
• added init scripts for SuSE, RedHat and Debian (Debian init scripts are in debian packages only)
• improved packaging for SuSE and RedHat
• found a maintainer for Debian packages who is much better equipped to create Debian packages than I am ;-)

• the cardfsd (card file system daemon) which has been used by LUFS (Linux Userland FileSystem). LUFS is nevertheless a very interesting project, but I didn't get any feedback about this, so I decided not to port it to LibChipCard 0.7.
  However, the Card Filesystem (which is used by KPassCard)is still supported.
• KCardDebugger: This tool looked quite nice, but while implementing new card classes I found it wasn't very helpfull (the extremely simple tool cardcommander was very much mor of help)

• added a new module to chameleon: "logger". This is now used by the debug macros to dump debug messages either to stderr, a file or syslog. The new logger even allows to dynamically change the log level (this feature is needed by chipcardd)
• chipcardd now uses the "logger"
• updated manpage of chipcardd to reflect the changes
• added handler for signals "USR1" and "USR2" to chipcardd. They have the following meaning:
  • USR1: increase log level by one (making chipcardd more verbous)
  • USR2: decrease log level by one (making chipcardd less verbous)
• hbcicard now checks for a keypad instead of assuming the reader has one

• changed caption of service edit dialog
• KCardSetup now uses reasonable defaults if the configuration file does not exist (fixed a bug, since it was intended to work this way before)
• added German translation to KPCSCSetup

• Debian 3.0
• SuSE 8.0
• RedHat 8.0
• FreeBSD 4.6.2

• fixed many bugs reported in the last few days
• added manpages for chipcardd and the configuration files
• documented the example configuration files
• improved KCardSetup (it now scans for all known drivers, improved help, enabled a button which previously was without any function etc)
• added a German translation to KCardSetup
• debugged hbcicard
• added some checks to readertest to catch segfaults

• fixed many bugs reported in the last two days
• KCardSetup now scans for all known drivers upon first opening of the reader edit page
• KCardSetup now features a complete German translation
• slightly improved help texts for KCardSetup
• removed the last occurrences of the deprecated chroot_dir in the Makefiles
• added manpages for the configuration files

• I updated the API documentation of LibChipCard and created a package. You can download it from my download page (see links in the menu on the left).
• If all works fine I will release a first stable version at the end of this year.
  Please use the time available until then to report any persisting bugs, because in the first three months of the next year I won't have much time (working an an exam).

• this error occurrs when you have no pcsc (libpcsclite.so) installed on your system. It prevents the readertest from succeeding, it rather returns an error. This bug is fixed in the current CVS repositiory, so I recommend checking out the module libchipcard-current. The KDE tools themselves are not affected. If CVS is not suitable for you then please replace the existing file ctcore.c in src/libchipcard/engine/reader by this one.

• libchipcard-0.7beta3.tar.gz, and
• libchipcard-kde-0.7beta3.tar.gz

• moved KDE tools into their own package (LibChipCard-KDE). They are now available in their own CVS module (libchipcard-kde)
• improved spec file for RPMs (we now have a normal package and a development package, and both packages are very much smaller than the 0.6.1 packages)
• hopefully fixed a bug in KDE 3.1 detection (not tested yet)
• fixed problems with autotools (removed usage of chroot_dir and replaced it with DESTDIR)

• the current beta2 does not allow using the keypad of a reader to change the pin of a RSA card. So if you want to use it anyway you will need the new rsacard.cmd file which can be obtained via CVS (or downloaded here)
  However, verifying the pin using a keypad works.

• added a new card class: CTGeldKarte. This class supports the so called "Geldkarte" functionality of Eurocheque cards. Most bank cards in Germany have this functionality.
• added a new tool: geldkarte, which shows some information about a GeldKarte (such as amount of money loaded onto the card)
• ported KMedicalCard to version 0.7 of LibChipCard. This KDE tool isn't very beautiful, and it does no important things, but it basically shows how to use LibChipCard from GUI applications.
• fixed some bugs in the autotools files (Makefile.am)
• finished the class for RSACards
• improved tool hbcicard: It is now able to show some information about bank accounts stored on a RSA card. It automatically detects the type of the inserted card (DDV or RSA).
• fixed some bugs in the server code (waiting for a card now works)
• added virtual method CTCard::doCallBack to allow C++ code to overload and thereby intercept call backs

• I've heard about problems compiling KCardSetup when there still is the old 0.6.1 (or even older version) installed. If this problem occurrs with your system then please remove or at least rename /usr/local/include/chipcard.h.
  That should fix it. I will have to fix this problem in LibChipCard itself before the stable release.
  

• this version has been completely rewritten in C to be much leaner and maybe even faster
• major changes:
  • LibChipCard introduces a chipcard daemon which is required to be running to allow access to your card readers.
  • added a German medical card daemon (as requested by a Gnumed developer)
  • added a console debugging tool which allows very low level debugging of card classes
  • improved KCardSetup, the KDE setup tool for LibChipCard, which is now able again to test readers before writing the configuration file
  • introduced a configuration file based APDU engine which allows to add/adapt commands to your cards and readers without the need to recompile LibChipCard itself.
  • the new C API allows asynchronous access to the card readers
  • the old C++ API is still in use and under heavy development. IT is now more or less of a wrapper around the C core.
  • it supports basic CTAPI drivers and PC/SC (Unices only)
  • this version has been tested with FreeBSD 4.6.2 (clients and server) and Linux (Debian 3.0, Redhat 8.0) and is known to compile with KDE2/KDE3 and gcc 2.95.x/gcc 3.x.

• added the tool cardcommander, which allows sending raw APDUs (commands) to the chip card
• fixed a bug in the configuration file driven command engine
• further cleanups

• added daemon for German medical cards (as requested by Karsten Hilbert from Gnumed half a year ago). This daemon waits on all readers for the insertion of a German medical card. If there is one its data will be read and written to a file. Since the poll rate for the ChipCard daemon can be set (and defaults to 750 milliseconds) this daemon (and the card daemon) do not impose much load on your system.
• splittet CTCard::waitForCard in three parts (the original method is still available), so that you can now check all cards. This was needed for the medical card daemon, but is quite usefull for other purposes, too. You can now start listening for status changes (startWaitForCard), actually listen for the change (checkWaitForCard) and stop listening (stopWaitForCard).
• now the installation prefix is honoured throughout the package, so when you install to /usr/local then the configuration files are expected in /usr/local/etc, and the command files are expected in /usr/local/share/libchipcard/commands.
• other minor cleanups

• added the tool readertest which checks whether a given reader is usable by LibChipCard
• added a feature to KCardSetup which allows checking a card reader before saving the configuration (which internally calls readertest)

• current version contains all needed files (especially the command files, example configuration files, etc.)
• it compiles under gcc 2.95 and 3.2, so it works now with RedHat 8.0, too
• it compiles and works under FreeBSD 4.6.2, too (both client and server). This has been tested with a Towitoko Chipdrive Micro in CTAPI mode.
• OpenHBCI, the main user of LibChipCard works with the current CVS version (and so does AqMoney)
• summary: the current CVS version is basically usable now ;-)
• hopefully I can release a new beta at the end of the week ;-)

• added CTAPI driver mode (still testing with a Kobil Kaan pro)
• started removing obsolete parts of LibChipCard
• improved chipcard daemon (now forking and handling signals, if available)

When compiling the tarball you must specify the installation prefix with --prefix=/usr/local. If you don't it will be installed to /usr/local/libchipcard, where most depending projects won't find it.
This only applies to the tarball, all binary packages are installed to correct locations.

• KCardSetup, the graphical (KDE) setup tool for LibChipCard, now works again
• disabled obsolete parts of LibChipCard, so a simple make will now compile the new parts only
• LibChipCard v0.7 slowly becomes usable ;-)

• adapted the console tools, they are now available with the current CVS version again.
• adapted CardFS, it is now included in libChipCard again.
• I will now have to adapt KCardSetup to reflect the changes in the configuration files.

• finished the old CTCard interface, so that at least the test tools work again
• added some example files for the command engine
• I will now have to remove the old libchipcard stuff and start to rewrite the KCardSetup tool, since the format of the configuration files has changed

• finished configuration file driven command engine. This allows to extend and adapt LibChipCard by simple additions of configuration files. I will later provide configuration files for each directly supported chip card
• finished a basic chipcard daemon (still lacks some necessary protocol messages, but it basically allows to connect/disconnect a chip card and send commands to it)

• it is small (since the server itself and the libchipcard core is now in C instead of C++)
• it is faster than it would be in C++, because of reduced copy operations (well, I guess that would be possible in C++, too, but in C it is quite natural, since there is no "string" class ;-)
• it uses strong encryption (RSA and Blowfish) for client-server communication
• it is single threaded while using asynchronous network functions (on client and server side)
• it now allows to asynchronously execute chipcard commands (you issue the command and your program can do other thing while waiting for the result, e.g. keeping the GUI updated etc)

Implemented so far

• basic chipcard service (using RSA and Blowfish to encrypt the client-server communication)
  • Allocate and release a reader: This allows to select a reader by some parameters, such as reader type, properties like hasDisplay or hasKeypad)
  • Connect and disconnect a reader
  • Send a APDU (command) to the card and retrieve the answer
• access to the card reader using PCSC (the CTAPI framework will be added as soon as the rest is standing)