On 2/7/2011 4:49 PM, Andre Zepezauer wrote:
> On Mon, 2011-02-07 at 16:00 -0600, Douglas E. Engert wrote:
>>>> Attached is a patch that implements a sc_ctx_use_reader, to pass in two
>>>> void
>>>> pointers to an underling driver. The code to use this from cardmod.c to the
>>>> cardmod code in reader-pcsc.c (or where ever it ends up) will be added as
>>>> part
>>>> of a much larger patch.
>>>>
>>>> The intent is to keep this sc_ctx_use_reader patch simple and small so it
>>>> can be committed soon.
>>>
>>> The essence of both proposals side-by-side¹:
>>
>> Actually not.
>>
>> The use_reader version can be called multiple times to change the handles
>> as this is one of the major issues I found with the way the BaseCSP calls
>> the cardmod. The cardmod.c can then call sc_ctx_use_reader just after
>> the call to sc_context_create, and can call it later if the BaseCSP
>> provides different handles.
>
> Why not calling sc_context_create() for every pair of "hSCardCtx,hSCard"
> the cardmod is unaware of?
I was trying to avoid the additional overhead or recreating the sc_context,
and only back up as far as needed. During login, there are multiple
processes involved, and it might be that a handle is passed between processes,
or new handles obtained, so any caching done by OpenSC code may or may not
be valid.
> From a context created in that way a new
> p15card can be instantiated. And that would let to a nice one-to-one
> mapping between "hSCardCtx,hSCard" and p15cards.
That assumes that the Microsoft code has not changed something between calls,
as the BaseCSP may reset, or issue commands to the reader. The only assumption
I am making is that if the handles provided in the pCardCtx have not changed
the handles are still valid.
>
>> From a pair of "hSCardCtx,hSCard" (provided with every call) you can
> then easily lookup the right p15card. And everything else goes as usual.
>
>
Today the opensc cardmod driver is experimental and it has issues
that preclude its use by login:
(1) It tries to use the registry to pass handles
(2) It does not have a Decrypt function
(3) It makes assumptions about the handles that are not valid
(4) It has a number of other bugs
Its debugging code only takes affect after the sc_context is created,
much too late to trace some important events.
It requires test machines that are members of an AD domain and the
user must have a smart card with certificates trusted for login.
I have such an environment, and have fixes for all of these that I
intend to commit. The missing piece is the use_reader patch that is needed
for (1) and (3). Martin has outlined what he would accept, and I have
provided that, and intend to commit it too. This will give us a working
cardmod driver so others can test additional changes.
There are still lots of changes that could be made to improve
performance, installation and add features. A single DLL,
use manifests, and side-by-side assemblies, one or may
registry entries for the ATRs of cards supported by OpenSC
there are a lot of possible improvements.
My goal this week is to get the use_reader patch committed,
as well as the other fixes to the cardmod code.
After that if you have improvements and a way to test them,
please try them.
--
Douglas E. Engert <deeng...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
