sf1 / go-card

PC/SC client written in Go. Currently not maintained
MIT License
41 stars 23 forks source link

Merge with ebfe/scard? #1

Closed AndreKR closed 5 years ago

AndreKR commented 5 years ago

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, the Reader struct with IsCardPresent() and WaitForCardPresent().

How do you feel about merging those features into ebfe/scard?

See also: https://github.com/ebfe/scard/issues/14

sf1 commented 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.

bluetech commented 5 years ago

@sf1 I am curious, why did you choose to bypass libpcsclite and go directly to the daemon?

AndreKR commented 5 years ago

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.

sf1 commented 5 years ago

@bluetech The main reason was to avoid using cgo.

bluetech commented 5 years ago

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.