Deimos-like binding to libopensc (reduced extend required by external modules [driver/SM])
|Copyright||Copyright © 2017, Carsten Blüggel|
|Registered by||Carsten Blüggel|
To use this package, put the following dependency into your project's dependencies section:
D language: Deimos-like binding to libopensc, current C-source version 0.16.0, released June 2016
The OpenSC framework allows for providing e.g. a smart card driver (or Secure Messaging module) as external shared object/DLL, if opensc.conf is configured accordingly.
This binding allows to implement in the D programming language.
Not all opensc header content is covered, but what is required/usefull for external modules (smart card driver/SM).
There is a small, undisturbing deviation concerning cards.h/cards.d: SCCARDTYPE_ACOS5... where the driver, I'm implementing, is involved.
Currently, this library can deal with 2 versions (API/exports) of libopensc's C source/header/library binary: 0.15.0 and 0.16.0. No more, and I'm thinking about to drop 0.15.0 and to support the latest only, because distinction of cases get's complex/time-consuming,resulting in ugly code etc..
Simply requiring the latest, incuring possibly requirement to manually build opensc (which is pretty straight forward) would be much easier for me than explaining all that stuff.
sudo apt-get install pkg-config openssl libssl-dev libpcsclite-dev libltdl-dev libreadline-dev
There are multiple reasons why code using this binding has to tell at compile time, whether it's going to be linked against a libopensc binary version 0.15.0, or the latest version 0.16.0. As of now, this is managed by the version identifier FAKEOPENSCVERSION (more on this and other version identifiers in info/options).
I've no clue, if it's possible to automate this, thus use of FAKEOPENSCVERSION (ore not) has to be adjusted manually appropriately in external module's dub.json file.
I'm not going to investigate APIs below 0.15.0 and if they require special handling within this binding. In other words, You are save only with release binary versions>=0.15.0 (which is available e.g. in Ubuntu since wily 15.10).
There is another anomaly refering to opensc-0.15.0.tar.gz tarball downloadable from sourceforge: Different release source code under the same version number, same file name: What I downloaded in 2015 is different from what You can download now; thus I even can't know which content of version 0.15.0 was picked by package maintainers (git or a possibly different tarball ?); I'm refering to a version 0.15.0 dated 2015-05-16 (another felicitous reason to drop supporting version 0.15.0)
The binaries opensc-pkcs11.so/.dll, libopensc.so/.dll and others from opensc implicitely know their common own version and can report it (let's assume, the package was built from C-source version 0.15.0, thus version string is "0.15.0"). The same applies to an external module (e.g. my module acos564 knows it's internal version string, which currently is "0.16.0", meaning that it can deal with all opensc framework versions (that this package supports) upto "0.16.0", and can/must be able to report this value). After a successfull dlopen of an external module, the opensc framework checks for matching version strings (opensc framework <-> external module) and rejects the external module in case of mismatch, otherwise it reports (if enabled) to the /tmp/opensc-debug.log file: successfully loaded card driver 'e.g. acos564'. Without further provisions, driver acos564 will be rejected in this example. This is where the version identifier FAKEOPENSCVERSION first came into play. When set during build of the acos564 external module, it will cause acos564 to report/mirror the opensc framework version, not its own version. As side effect in this case of 2 choices, a set FAKEOPENSC_VERSION implies for this binding, that the API of version 0.15.0 has to be exposed during compilation.
System dependency: libopensc.so/.dll (depending on usage possibly also libsmm-local.so/.dll) [https://github.com/OpenSC/OpenSC/wiki], which in turn depends on openssl.