The protocol used between libpcsclite and pcscd (src/winscard_msg*) is defined in terms of types which depend on the native word size. This is a problem because there are platforms out there which support running programs with multiple word sizes on the same system. For example, Linux on x86_64. On systems like that, only clients whose word size agrees with that of pcscd will work.

I haven't tried fixing this yet, so I don't know how much of a pain it's going to be. I imagine that doing it right is going to require going to a new protocol version which uses elements of explicitly-defined size, probably the same as those currently used on 32-bit platforms. I'd hope that pcscd would support both the new protocol and the old, word-size-dependent protocol, at least for a while.

I imagine that a similar issue will bite people using Intel-based MacOS boxes, if it hasn't already. Those systems can support binaries with two different byte orders on the same machine. So, when the word size issue is fixed, it might not be a bad idea to switch to using network byte order instead of native at the same time.

After some soul-searching, I decided take a route that should have less pain in the long run, at the possible cost of some short-term pain. I decided to change the offending typedefs in wintypes.h to match what their sizes would be on Windows (DWORD in win64 is still 32 bits, as is LONG i believe).

Because this changes the signature of functions and structs, I've bumped the sonumber on the libraries. I thought about only doing this for 64-bit, since this really doesn't change anything for 32-bit, but that seems like more long-term pain that it is worth.

After making this change, I am able to use certificates in a 32-bit mozilla talking to a 64-bit pcscd.

I've done a new patch, changing only the internal wire protocols as you suggest. It was indeed a little bit trickier, but not too difficult.

I've included a "wirecheck" program which will check for changes to the structs that are not word-size compatible. Even thought it is a generated file, pcsc-wirecheck-dist.c should *not* normally be rebuilt; only when you know you are breaking compatibility. We used a similar tool when I worked on Lustre.

Note that while this patch retains both binary and source compatibility with previous versions, it does break the wire protocol and so pkcs11 modules with forked versions of pcsc-lite (i've run into a couple) will break. I am ok with that.

On machines like intel-based Mac's, you can have software using both byte orders on the same machine. So, a PPC application would not be able to talk to an x86 pcscd, because of the byte order problem.

Incidentally, I was originally OK with making a backward-incompatible change to the wire protocol and requiring people to upgrade pcscd and clients at the same time. However, now that there are Linux distributions which include pcsc-lite and ship both 32- and 64-bit libraries, we're going to start seeing problems like Eric Andry's, where people try to build pcsc-lite from source and it doesn't interop with the vendor's pcscd (or, they install the new one and it doesn't interop with the vendor's apps). It would be nice if we could figure out how to prevent this, at least in the common cases.

> On machines like intel-based Mac's, you can have software using both byte orders on the same machine. So, a PPC application would not be able to talk to an x86 pcscd, because of the byte order problem.

No. The PPC application is _emulated_ using Rosetta. And I hope Rosetta will switch the bytes when needed. The PPC application will not talk directly to pcscd or to libpcsclite.

But I am not sure a PowerPC PC/SC application is supposed to run within Rosetta.

Sure, but won't the PPC application also be linked against a PPC version of libpcsclite, which will also be emulated? I can't imagine this working any other way; allowing calls from PPC code to x86 libraries is infeasible except when the emulator completely understands the ABI and thus knows things like which parts of a structure are words that require byte-swapping.

Similarly, the emulator can't know that aboud data structures written to disk or sent over the network or to another process, so it can't convert those, either. So if you want PPC and x86 programs to communicate with each other, the message formats they use need to not depend on the host byte order.

Now, we don't currently support MacOS in our computing environment, so I don't much care if the byte-order issue is addressed or not. But I do think it's a real issue, and if a backward-incompatible protocol change is needed anyway to deal with the word size problem, then it seems like a perfect opportunity to kill two birds with one stone.

OK. Given that the protocol major version changes, I think I can see how to make a pcscd that can talk to old 32-bit, old 64-bit and new clients. Once Jabob's patch is stabilized and integrated, I'll work up a patch to add backward-compatibility. Also, XXX has convinced me that it's probably not a big deal if you can't run PPC PC/SC applications within Rosetta.

That just leaves testing. The offer of a 64-bit VM still stands, though I'll have to dig around a bit to find a reader I can use for that. The easiest thing to come up with is probably a cryptoflex e-gate card.

You might want to try a distro that's setup to work with mixed 64-bit/32-bit like FC6.

I run FC6 x86_64 kernel on a Dell laptop that has the Core 2 Duo.

It separates 32-bit from 64-bit libs with the structure:

/lib64
/usr/lib64

vise

/lib
/usr/lib

When I wanted to test the 64-bit patched daemon I compiled, targeted, and installed to

/usr/local/lib64
/usr/local/bin

and kept the /etc/init.d/pcscd
and /usr/sbin/bin/pcscd

script and binary.

Then I modified the startup script to point to the patched binary rather than the one from the distribution.

Since my last post, I also tried removing all 64-bit pcsc packages and drivers and installed 32-bit daemon, associated tools, ccid, and libcoolkey. The combination x86_64 kernel and 32-bit ccid driver worked with an external keyboard with built-in smart card reader. However the laptop internal reader did not work. I'm not a kernel/C/C++ hacker to understand why the 32-bit ccid driver worked with the keyboard and not the internal reader.

Eric:
You haven't said exactly what Dell laptop you have, but chances are the internal reader didn't work because it's simply not supported. Sufficiently recent machines have an O2Micro reader (USB ID 0b97:7772) which is not supported by the CCID driver today, but will be shortly -- Chaskiel and I worked out what was needed a couple of days ago, and I'll be sending patches as soon as I have a spare moment.

As for other status, I'm not sure. I was going to work up a patch to allow a new server to handle both old and new clients, but simply haven't had a chance -- I've been very busy the last couple of months getting our F7 support ready here, and PC/SC simply hasn't been on the radar (except for getting my new laptop to work :-)). I expect to have some time to spend on this starting the week after next.

I don't know if there are any other issues preventing integration of Jacob's patches. If not, then maybe it's better to do so now than to wait for the backwards-compatibility stuff. That's up to Ludovic.

Your right, I should have said what kind of card reader I am using. My Dell D820 laptop's internal card reader DOES work when I was running FC6 x86_64.

I've upgraded to F7, and the card reader works when using all 32-bit drivers and OS. I knew the support for 64-bit to 32-bit server communication would take a while, so when F7 came out, I opted for 32-bit.

Using the 1.4.0 patch, PCSC-Lite mostly works, however it does not work well w/ TokenStatus called from a 32-bit app:
It does not return failure-state when the token is removed.
It does not fill in the ATR.

This was a nasty bug to discover... since I was thinking that it was in my app, rather than PCSC-Lite...