Hi!
> > One of the longstanding problems of OpenSC is lack of documentation,
> > both developer (source comments, internal architecture, tutorials on
> > how to add new card drivers other way than copypaste etc) and
> > end-user docs. This is unfortunately quite usual for open source
> > projects, especially for niche project that does not attract a huge
> > crowd of volunteers and where some companies could even sometimes
> > take lack of documentation as a competitive edge. This is not a
> > trivial thing to fix, especially for source code, which is not as
> > "sexy" as end-user documentation. Not that I would want to suggest
> > a "8 meters requirement" [1], something should be done about it.
> > [...]
>
> I agree:
>
> In the writting of Spanish DNIe LGPL driver I've found so many times
> that lack of information. A simple tutorial for writting card
> drivers, An overview of what iso7816.c does, differences between
> sc_xxx functions an their counterpart iso_xxx functions, how
> sc_transmit_apdu handle 61xx status response, how an when issue
> apdu->{resp,resplen,le} and what should be expected....
>
> At this moment, I'have cwa14890 Secure Messaging working for DNIe, but
> I'm next to !wrap and rewrite! sc_transmit apdu()... because I
> _really_ doesn't know the exact way of handling a correct
> get_response() (required on every SM apdu message) cmd when expected
> data length is not known in advance or when a previous function is
> already waiting for a response in their apdu
>
> So I really (really!) need a documented API and description on what is
> expected for each routine Perhaps not indeed to make a public API (
> opensc-devel ), just a short of "Developer's guide" [...]Developers can afford to read the source. Especially if you think about extending opensc, you need special insights... But you're right, things could be a little easier. There has been a some discussion about SM, OpenSC doesn't offer a possibility to get your hands on *each* APDU before/after sending. In the source code you can find comments about sm_transform. Although this would be the best solution, it is only planned for future releases. Apart from patching OpenSC and adding support for sm_transform you could also use a workaround: As far as I can see, Viktor doesn't use a wrapper to sc_transmit_apdu as you once suggested. Instead he uses a "remote reader" to encode/encrypt data for SM. I am using a separate library, where a SM wrapper calls sc_transmit_apdu. > Anyway, regardless of mainstream comments in source code, I expect get > DNIe ready for public test at the end of this month. Frank, Victor, > perhaps you can find usefull to take a look to cwa14890 SM code Nice to hear that, although your blog posts looks like you need some more work on SM... From what I have seen in your code, you are using Viktors approach to treat every bit of SM card specifically. Although I am preferring a more generic approach to exclude the (ASN.1) encoding of APDUs in a card independent layer, yours (and Viktors) is more straight forward. Greets, Frank.
pgp8Vvy6pLeQh.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
