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

Martin

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

Reply via email to