[Pcsclite-muscle] IFD polling

Sat Feb 28 02:40:35 UTC 2015

On Fri, Feb 27, 2015 at 6:38 PM, William Roberts <bill.c.roberts at gmail.com>
wrote:

>
>
> On Fri, Feb 27, 2015 at 2:58 PM, Frank Morgner <
> morgner at informatik.hu-berlin.de> wrote:
>
>> I doubt that there is a reasonable generic and non-complex way of doing
>> this via jni. You said it before, you would have to start the JVM from
>> pcscd's process space. I bet you will end up hard wiring any possible
>> configuration in the process.
>>
>
> I can pass any information in the DEVICENAME needed, just like the
> pipe/socket models.
>
>
>>
>> OR you could just delegate the calls to a different Java based process
>> (which allows this flexibility) AND use some inter process communication
>> between pcscd and your java backend. And then you end up with a socket
>> interface a pipe or similar ;-)
>>
>
> Both are logically the same, your just replacing function calls to IPC
> pipe/socket command interface.
> So the quality of the abstraction has to do with the interface design
> mostly, not IPC/func call.
> In fact I almost have a working bridge. It's a bit more work, but reduces
> the amount of memory
> consumption on the system (1 less process), and removes one layer of IPC.
> I am almost actually done.
>
> One nice thing I can do, is detect based on the methods, and attributes of
> the
> implementing Java class, whether or not its supporting various things and
> handle
> some of the rawness of the IFD API. Which the current loader for the .so
> can't
> handle. The docs say to implement either
> IFDHCreateChannelByName or IFDHCreateChannel. However, the loader
> requires both symbols in the .so and fails if missing. It should check for
> one or
> the other, not both (both should be ok too).
>
> Looking at IFDHTransmitToICC() the paramater PSCARD_IO_HEADER RecvPci
> is not clear to me. Looking at:
> bitbucket.org:mrts/pcsclite-softemu-ifdhandler.git
> That code doesn't even use that argument, so I guess
> I can ignore it, but whats its purpose?
>
> Also looks like Send version is unused too.

>
>
>> Greets, Frank.
>>
>> On Friday, February 27 at 10:04AM, William Roberts wrote:
>> > I might be able to contribute a Generic Java binding for the ifd layer
>> as
>> > well.
>> >
>> > On Fri, Feb 27, 2015 at 8:31 AM, Frank Morgner <
>> > morgner at informatik.hu-berlin.de> wrote:
>> >
>> > > Yes, the documentation needs some love, but I think for a bunch of
>> spare
>> > > time projects its quite OK. I'll move the example cases to the sub
>> > > components where the generic use is outlined, too.
>> > >
>> > > Am 25. Februar 2015 21:24:19 MEZ, schrieb Martin Paljak <
>> > > martin at martinpaljak.net>:
>> > >>
>> > >> Hello Frank,
>> > >>
>> > >> Maybe you should publicise your virtualsmartcard project better or
>> > >> have the architecture or more precisely, various use cases,
>> documented
>> > >> even better or integrate the knowledge of these projects into
>> > >> mainstream documentation. I did not look that much into it before
>> > >> because I just did not understand what it was or if it related to
>> > >> something I could use. Because most of the documentation was about
>> > >> "virtual smart cards" and "nPA" and other German-specific terms, I
>> > >> figured out that probably not relevant for me.
>> > >>
>> > >> BUT it turned out that your project contains a lot of useful
>> universal
>> > >> APDU/PC/SC layer plumbing stuff that could really be used more  (like
>> > >> contact->nfc relay, remote ifdhandler etc)
>> > >>
>> > >> Stuff for what support should be more integrated in open source
>> > >> projects, really handy for debugging, testing and prototyping.
>> > >>
>> > >> Thanks & cheers
>> > >> --
>> > >> Ma!
>> > >>  rtin
>> > >>
>> > >> +372 515 6495
>> > >>
>> > >>
>> > >> On Wed, Feb 25, 2015 at 6:34 PM, Frank Morgner
>> > >> <morgner at informatik.hu-berlin.de> wrote:
>> > >>
>> > >>>  You can delegate the calls e.g. by using jni.
>> > >>>
>> > >>>  I am using a simple socket based interface for delegating the ifd
>> requests,
>> > >>>  see
>> http://frankmorgner.github.io/vsmartcard/virtualsmartcard/README.html
>> > >>>  VPCD delegates the calls to everything that listens on the other
>> side of the
>> > >>>  socket. You can find a java implementation of "the other side" in
>> this
>> > >>>  android app
>> > >>>  http://frankmorgner.github.io/vsmartcard/remote-reader/README.html
>> > >>>
>> > >>>  Am 25. Februar 2015 17:01:19 MEZ, schrieb Jeffrey Hutzelman <
>> jhutz at cmu.edu>:
>> > >>>
>> > >>>  On Wed, 2015-02-25 at 07:42 -0800, William Roberts wrote:
>> > >>>
>> > >>>>
>> > >>>>   On Wed, Feb 25, 2015 at 7:28 AM, Ludovic Rousseau <
>> > >>>>   ludovic.rousseau at gmail.com> wrote:
>> > >>>>
>> > >>>>
>> > >>>>>   2015-02-25 12:16 GMT+01:00 William Roberts <
>> bill.c.roberts at gmail.com>:
>> > >>>>>
>> > >>>>>>
>> > >>>>>>   That's from the client application side. I was looking for a
>> java
>> > >>>>>>
>> > >>>>>
>> > >>>>>   binding to
>> > >>>>>
>> > >>>>>>
>> > >>>>>>   the ifd
>> > >>>>>> interface.
>> > >>>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>>   Why do you want to call the IFD handler directly from Java?
>> > >>>>>   Why not use the PC/SC
>> > >>>>>  interface?
>> > >>>>>
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>>   I am not explaining this properly :-P
>> > >>>>
>> > >>>
>> > >>>
>> > >>>  Perhaps not.
>> > >>>
>> > >>>  I think what you're asking for is effectively the ability to write
>> an
>> > >>>  IFD handler in Java.  For pcsc-lite, I don't think that's
>> realistic --
>> > >>>  it would mean pulling an entire Java interpreter into pcscd.  What
>> you
>> > >>>  could do is a bridge that talks to a Java program running in
>> another
>> > >>>  process, but I think that's going to be more troublesome than it's
>> > >>>  worth.
>> > >>>
>> > >>>  jPAM in fact does not do this; what it does is let Java
>> applications
>> > >>>  call PAM, not the other way around.  pam-python _does_ let you
>> write PAM
>> > >>>  modules in Python; it does this by spinning up a Python
>> interpreter in
>> > >>>  the PAM module.  That works because Python is designed to be
>> embedded in
>> > >>>  a!
>> > >>>  nother
>> > >>> program in this way and because it will be shut down and
>> > >>>  unloaded when the module is removed, which happens no later than
>> when
>> > >>>  the application calls
>> > >>>  pam_end().
>> > >>>
>> > >>>  -- Jeff
>> > >>>
>> > >>>
>> > >>> ------------------------------
>> > >>>
>> > >>>
>> > >>>  Pcsclite-muscle mailing list
>> > >>>  Pcsclite-muscle at lists.alioth.debian.org
>> > >>>
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
>> > >>>
>> > >>
>> > >>
>> > >>  --
>> > >>  Frank Morgner
>> > >>
>> > >> ------------------------------
>> > >>
>> > >>  Pcsclite-muscle mailing list
>> > >>  Pcsclite-muscle at lists.alioth.debian.org
>> > >>
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
>> > >>
>> > >>
>> > > ------------------------------
>> > >
>> > > Pcsclite-muscle mailing list
>> > > Pcsclite-muscle at lists.alioth.debian.org
>> > >
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
>> > >
>> > > --
>> > > Frank Morgner
>> > >
>> > > _______________________________________________
>> > > Pcsclite-muscle mailing list
>> > > Pcsclite-muscle at lists.alioth.debian.org
>> > >
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
>> > >
>> >
>> >
>> >
>> > --
>> > Respectfully,
>> >
>> > William C Roberts
>>
>> > _______________________________________________
>> > Pcsclite-muscle mailing list
>> > Pcsclite-muscle at lists.alioth.debian.org
>> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
>>
>> --
>> Frank Morgner
>>
>> Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
>> OpenPACE                        http://openpace.sourceforge.net
>> IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc
>>
>> _______________________________________________
>> Pcsclite-muscle mailing list
>> Pcsclite-muscle at lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
>>
>
>
>
> --
> Respectfully,
>
> William C Roberts
>
>

-- 
Respectfully,

William C Roberts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pcsclite-muscle/attachments/20150227/29476a77/attachment-0001.html>