2010/5/29 Martin Vogt <[email protected]>:
> On Sat, May 29, 2010 at 10:32 AM, Ludovic Rousseau
> <[email protected]> wrote:
>> 2010/5/29 Martin Vogt <[email protected]>:
>>> Hello,
>>>
>>> If logging support is compiled in,  the daemon segfaults in the lookup of:
>>>
>>> CommandsText[header.command]
>>>
>>> The attached patch verifies if the received data actually is a valid
>>> command.
>>
>> You need to use a patched libpcsclite to trigger this bug, right?
>>
> I have added a tcp/ivp4 transport, yes.
> Thus it was telnet localhost 4545
> <keyboard>+Return
> =>segfault :-)
>
> Currently I'm thinking to add a dbus session object for pcscd/pcsclite
> for linux hosts, but I'm unsure if this is usefull.

I was also thinking about adding dbus support. My idea was to write a
client application that talks to the daemon and is also a dbus server.
I do not want to add dbus support in pcscd itself.

One possible application I had in mind is to write a widget to display
the communication status. If an APDU is in exchange then this state is
visible. Many smart card reader do not signal when a communication
with the card is on going.

>> I do not understand your comment:
>> +        /** this marks the last command in the enum above. It cannt be part
>> +            of the enum itsself because the the protocal/CMDs
>> +            cannot be extended. */
>> +        #define CMD_ENUM_LAST  CMD_STOP_WAITING_READER_STATE_CHANGE
>>
>> I propose the attached patch instead.
>> Are you OK with it.
>
> At first I put it in the enum. But then I asked myself, that the infromation 
> how
> many enums are in the type pcsc_msg_commands, is not a command by ittself.
> Therefore I put this information outside the enum.
>
> But I can't think of a problem if there are different version of 
> pcsclite/pcscd
> interacting.
> eg:
> If someone extends the enum with CMD_COOL_FUNC1=0x15 and
> CMD_COOL_FUNC2=0x16 then
> the CMD_ENUM_LAST needs to be changed to 0x17. And now an old/new pcsclite 
> talks
> to a new/old pcscd.
>
> ==>should be no problem. yes.ok.

The client/server protocol has a version number

#define PROTOCOL_VERSION_MAJOR 4
#define PROTOCOL_VERSION_MINOR 0

If a client tries to use a newer protocol the server will deny the connection.
winscard_svc.c line 330


Patch committed in revision 4967. Thanks

-- 
 Dr. Ludovic Rousseau

_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle

Reply via email to