Chaskiel M Grundman wrote:
> the ccid spec supports using an interrupt pipe message to notify
> the host of card insert/remove events, but devices are not required
> to implement that part. Even for devices that do, I don't
> understand enough of how usb and libusb handle interrupt endpoints
> to k
Committed with some modification (single free).
Please review.
http://www.opensc-project.org/openct/changeset/1085
On 12/19/08, Ludovic Rousseau wrote:
> Hello,
>
> The tool cppcheck [1] detected a memory leak in src/ifd/ifd-cyberjack.c
>
> Checking ./src/ifd/ifd-cyberjack.c...
> [./src/ifd/i
On Fri, Dec 19, 2008 at 9:46 PM, Alon Bar-Lev wrote:
> Committed with some modification (single free).
> Please review.
I also prefer using one free() and some gotos.
Bye
--
Dr. Ludovic Rousseau
___
opensc-devel mailing list
opensc-devel@lists.opens
> >
> > I don't know. This is one of the things I don't know about usb apis.
> > Looking at the linux kernel code suggests that it might work, but it is
> > likely to be system dependent.
> >
>
> I don't mind to enable this feature on Linux and use current approach
> for other. It is just that no
On 12/19/08, Chaskiel M Grundman wrote:
> > I thought of polling the client socket and usb fds, so I exit the poll
> > if I got a command or something was sent from the reader.
> > Wouldn't this work?
>
>
> I don't know. This is one of the things I don't know about usb apis.
> Looking at the li
> I thought of polling the client socket and usb fds, so I exit the poll
> if I got a command or something was sent from the reader.
> Wouldn't this work?
I don't know. This is one of the things I don't know about usb apis.
Looking at the linux kernel code suggests that it might work, but it is
li
On 12/19/08, Chaskiel M Grundman wrote:
> > I thought to make the blocking poll() at ct_mainloop()
>
> The only reason ct_mainloop calls ifdhandler_poll_presence is so that the
> status file is updated. If we don't care about the status file anymore,
> then ct_mainloop doesn't need to know if th
> I thought to make the blocking poll() at ct_mainloop()
The only reason ct_mainloop calls ifdhandler_poll_presence is so that the
status file is updated. If we don't care about the status file anymore,
then ct_mainloop doesn't need to know if there's a card inserted or not.
> call a new
> method
On 12/19/08, Chaskiel M Grundman wrote:
> > I would like also to make the openct stop polling for readers if
> > possible (CCID supports this).
>
>
> I assume you mean "stop polling for CARDS".
Via the reader... :)
> the ccid spec supports using an interrupt pipe message to notify the host
>
> I would like also to make the openct stop polling for readers if
> possible (CCID supports this).
I assume you mean "stop polling for CARDS".
the ccid spec supports using an interrupt pipe message to notify the host
of card insert/remove events, but devices are not required to implement
that pa
On Thursday 08 May 2008, Alon Bar-Lev wrote:
> On 5/8/08, Antti Andreimann wrote:
> > I have a patch somewhere in my bitbucket that gets rid
> > of /var/run/openct/status and implements status functions by connecting
> > to existing AF_UNIX sockets instead. It's a bit slower, but It would
> > e
Andreas Jellinghaus wrote:
> Hi,
>
> maybe I can find some time to at least put out some new releases
> of everything (that has changes). is this a good idea?
Not sure if it a good idea to produce a release before Christmas.
What you want it to produce a pre release and get developers
to test i
> not sure if they follow this mailing list.
pkcs11-tool for Rutoken S is not yet supported (have problems).
pkcs15-tool is supported (almost all options).
Andreas Jellinghaus:
> Hi Pavel,
>
> can you check with the rutoken authors?
> not sure if they follow this mailing list.
> I neither hav
Hi Pavel,
can you check with the rutoken authors?
not sure if they follow this mailing list.
I neither have a token nor documentation (nor time right now),
so I can't be of any help.
rutoken is a new driver, so if it is not working 100% so far,
that is not a show stopper for the next release. but
Andreas Jellinghaus wrote:
> Hi,
>
> maybe I can find some time to at least put out some new releases
> of everything (that has changes). is this a good idea?
>
> are there any patches waiting for a merge?
> and show-stopper bugs we should fix before (or patched to undo
> if they don't work ok righ
Hello,
The tool cppcheck [1] detected a memory leak in src/ifd/ifd-cyberjack.c
Checking ./src/ifd/ifd-cyberjack.c...
[./src/ifd/ifd-cyberjack.c:390]: Memory leak: state
Defines=''
The state variable is allocated but not freed in case of error.
I propose the attached patch. I am not sure it i
Hi,
here is a new idea:
what about adding a parameter where users can pass the
APDU to format a cardos card, if they know it?
we could even add some checksum for the commands we know,
to prevent users trying the wrong commands. yes, the whole
situation is silly, but without help from siemens it w
On 12/19/08, Ludovic Rousseau wrote:
> I will try to merge my T=1 code in OpenCT. But not before a few weeks.
> I remembered some objections when I proposed to do this a few years
> ago. Maybe the situation has changed.
Great!
Thanks.
___
opensc-devel
On Thu, Dec 18, 2008 at 7:58 PM, OpenCT wrote:
> #31: T1 protocol abort handling
> ---+
> Reporter: alonbl | Owner: Chaskiel Grundman
>Type: defect | Status: new
> Priority: normal | Component: ccid
>
19 matches
Mail list logo
