Closed AndreKR closed 5 years ago
I certainly won't mind if anyone wants to have a go at this. The purpose of the ebfe/scard
project seems to be to provide a direct wrapper for the winscard C API though, while sf1/go-card
was meant to be a higher level interface from the beginning.
The implementations of the two projects are fundamentally different, especially on Linux/Unix where sf1/go-card
connects directly to PCSC-Lite daemon instead of going through any C library.
@sf1 I am curious, why did you choose to bypass libpcsclite and go directly to the daemon?
I don't know @sf1's reason, but I see the use of libpcsclite as a problem because it requires CGO, which, as we know, is not Go and also meant I had to do extra steps because I couldn't build my application on Alpine Linux because it doesn't use glibc.
@bluetech The main reason was to avoid using cgo
.
Avoiding cgo is great for cross compilation.
My major concern would be, is the libpcsclite <-> pcscd protocol stable? Unless told otherwise, I would assume it's an implementation detail which is subject to change.
Another approach would be to implement PCSC directly on top of USB (CCID is not too hard to implement). The problem with that is that access to USB is privileged by default on Linux (unlike, say, on Android, or on WebUSB (RIP)). Which I suppose is why libpcsclite went with the daemon architecture in the first place.
There is a lot of overlap between this project and https://github.com/ebfe/scard.
I am currently using ebfe/scard because I need
GetStatusChange
, but this project has some nice things too, like the ISO Command APDU factory functions, theReader
struct withIsCardPresent()
andWaitForCardPresent()
.How do you feel about merging those features into ebfe/scard?
See also: https://github.com/ebfe/scard/issues/14