From ludovic.rousseau at gmail.com  Wed Jun  8 08:29:44 2022
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Wed, 8 Jun 2022 17:29:44 +0200
Subject: [Pcsclite-muscle] Support for file-descriptor based devices in
 pcsclite
In-Reply-To: <2bde2748-aab1-5abe-ed58-284f3dda8daf@metacode.biz>
References: <ff932410-400c-42c1-615a-3a128898554f@metacode.biz>
 <CAGstE8AD6Z0gSsm6kmWbjW_cgVt90+01NxdMxJ3V2MS5KH0Ppg@mail.gmail.com> <2bde2748-aab1-5abe-ed58-284f3dda8daf@metacode.biz>
Message-ID: <CAGstE8DKPSr4nZWaSSs5azRf9eoHKvENumbKNatQJnGJuVE89w@mail.gmail.com>

Hello Viktor,

Any progress? :-)

Le jeu. 26 mai 2022 ? 11:24, Wiktor Kwapisiewicz <wiktor at metacode.biz> a ?crit :
>
> Hi,
>
> On 26.05.2022 11:13, Ludovic Rousseau wrote:
> > Sorry for the delay. Your email was in my spam folder (gmail).
>
> No worries, great to hear back from you!
>
> >> I did compile several small examples using libusb and
> >> libusb_wrap_sys_device and they worked fine with my tokens (Yubikeys).
> >> Now my question is whether support for
> >> LIBUSB_OPTION_WEAK_AUTHORITY/libusb_wrap_sys_device is something that
> >> could be considered for inclusion in pcsclite or is this out of scope?
> >
> > Yes, I could consider something like that.
> >
> > In fact I already have 2 issues opened for pcsc-lite and CCID with this idea.
> > "Open the device in pcscd and give the file descriptor to the driver"
> > https://salsa.debian.org/rousseau/PCSC/-/issues/20
> >
> > "Use libusb_wrap_sys_device() and avoid rescanning the USB bus"
> > https://salsa.debian.org/rousseau/CCID/-/issues/11
>
> Oh, I must've missed that issue tracker. I'll read them thoroughly.
>
> > This scheme could also be used on a "normal" computer and not only for Android.
>
> That'd be great for development too.
>
> > I am waiting for your first patches.
> > Good idea.
>
> Thanks for the ack! It may take some time as I'm not familiar with the
> codebase but I hope I can ping this mailing list in case I have
> questions/problems.

I propose to add a new function in the IFD Handler API.
https://pcsclite.apdu.fr/api/group__IFDHandler.html

Something like:
IFDHCreateChannelByFd(DWORD Lun, int FileDescriptor)

Then you can use libusb_get_device() to get a libusb device structure
from the file descriptor.
I expect some code refactoring in CCID src/ccid_usb.c to avoid
duplicating a large part of OpenUSBByName()

Bye

-- 
 Dr. Ludovic Rousseau


From wiktor at metacode.biz  Wed Jun  8 23:59:26 2022
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Thu, 9 Jun 2022 08:59:26 +0200
Subject: [Pcsclite-muscle] Support for file-descriptor based devices in
 pcsclite
In-Reply-To: <CAGstE8DKPSr4nZWaSSs5azRf9eoHKvENumbKNatQJnGJuVE89w@mail.gmail.com>
References: <ff932410-400c-42c1-615a-3a128898554f@metacode.biz>
 <CAGstE8AD6Z0gSsm6kmWbjW_cgVt90+01NxdMxJ3V2MS5KH0Ppg@mail.gmail.com>
 <2bde2748-aab1-5abe-ed58-284f3dda8daf@metacode.biz>
 <CAGstE8DKPSr4nZWaSSs5azRf9eoHKvENumbKNatQJnGJuVE89w@mail.gmail.com>
Message-ID: <60060e5d-36fa-eb52-e38c-8ab92d25c2c5@metacode.biz>

Hi Ludovic,

On 8.06.2022 17:29, Ludovic Rousseau wrote:
> Any progress? :-)

Sorry for the delay. The project was my holiday thing and since I 
returned to work I can't spend this much time on it sadly :(

The additional difficulty is that I wasn't able to find out how to get 
the USB device file descriptor on desktop Linux (I think you mentioned 
that this should be possible) so my work was done only on a phone 
(including writing, compiling and testing). Sadly Android has a 
different file layout than a regular Linux and (from my understanding) 
running a daemon that listens on non-standard Unix socket path (*not* 
/var/run/pcscd/pcscd.comm) would require also to compile the client 
library to also reference that non-standard path.

> I propose to add a new function in the IFD Handler API.
> https://pcsclite.apdu.fr/api/group__IFDHandler.html
> 
> Something like:
> IFDHCreateChannelByFd(DWORD Lun, int FileDescriptor)
> 
> Then you can use libusb_get_device() to get a libusb device structure
> from the file descriptor.
> I expect some code refactoring in CCID src/ccid_usb.c to avoid
> duplicating a large part of OpenUSBByName()

Thanks for your pointers! I've been looking at the code but 
unfortunately got stuck in hotplug_libusb.c that, ultimately, I figured 
out would not be needed since hotplug manages device additions and 
removals and USB file descriptor represents a ready device.

One additional problem: at least on Android there's an utility program 
that grabs the device and passes the file descriptor to another program.

An example: termux-usb -e ./usbtest /dev/bus/usb/001/002

This runs "./usbtest" with one argument: numeric parameter representing 
the file descriptor (e.g. "./usbtest 7"). The question is should pcscd 
be extended with an argument that it would use?

Also, if you have an idea on how could I test that on a regular desktop 
Linux distribution it would be super-helpful as debugging it on a phone 
is really inconvenient.

So: sorry for the delays but I can't currently spend the amount of time 
I would like to on this :(

Kind regards,
Wiktor


From ludovic.rousseau at gmail.com  Fri Jun 10 05:25:27 2022
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Fri, 10 Jun 2022 14:25:27 +0200
Subject: [Pcsclite-muscle] Support for file-descriptor based devices in
 pcsclite
In-Reply-To: <60060e5d-36fa-eb52-e38c-8ab92d25c2c5@metacode.biz>
References: <ff932410-400c-42c1-615a-3a128898554f@metacode.biz>
 <CAGstE8AD6Z0gSsm6kmWbjW_cgVt90+01NxdMxJ3V2MS5KH0Ppg@mail.gmail.com>
 <2bde2748-aab1-5abe-ed58-284f3dda8daf@metacode.biz> <CAGstE8DKPSr4nZWaSSs5azRf9eoHKvENumbKNatQJnGJuVE89w@mail.gmail.com>
 <60060e5d-36fa-eb52-e38c-8ab92d25c2c5@metacode.biz>
Message-ID: <CAGstE8DUC1CKtRXvKYVo+RvhzRUqW4JmzZyAojQh1c5ps==VfQ@mail.gmail.com>

Le jeu. 9 juin 2022 ? 08:57, Wiktor Kwapisiewicz <wiktor at metacode.biz> a ?crit :
>
> Hi Ludovic,

Hello Wiktor,

> The additional difficulty is that I wasn't able to find out how to get
> the USB device file descriptor on desktop Linux (I think you mentioned
> that this should be possible) so my work was done only on a phone
> (including writing, compiling and testing). Sadly Android has a
> different file layout than a regular Linux and (from my understanding)
> running a daemon that listens on non-standard Unix socket path (*not*
> /var/run/pcscd/pcscd.comm) would require also to compile the client
> library to also reference that non-standard path.

You can use the environment variable PCSCLITE_CSOCK_NAME to indicate
the socket name you want to use
See https://ludovicrousseau.blogspot.com/2010/11/pcsc-client-and-server-on-two-different.html

My initial idea was to open the USB device in src/hotplug_libudev.c.
And then give the file handler to the driver.
The device is already found by the pcscd hotplug mechanism so we do
not need to rescan the USB bus in the CCID driver.

The problem is different on Android since you get the file descriptor
from *outside* of pcscd.

> > I propose to add a new function in the IFD Handler API.
> > https://pcsclite.apdu.fr/api/group__IFDHandler.html
> >
> > Something like:
> > IFDHCreateChannelByFd(DWORD Lun, int FileDescriptor)
> >
> > Then you can use libusb_get_device() to get a libusb device structure
> > from the file descriptor.
> > I expect some code refactoring in CCID src/ccid_usb.c to avoid
> > duplicating a large part of OpenUSBByName()
>
> Thanks for your pointers! I've been looking at the code but
> unfortunately got stuck in hotplug_libusb.c that, ultimately, I figured
> out would not be needed since hotplug manages device additions and
> removals and USB file descriptor represents a ready device.
>
> One additional problem: at least on Android there's an utility program
> that grabs the device and passes the file descriptor to another program.
>
> An example: termux-usb -e ./usbtest /dev/bus/usb/001/002
>
> This runs "./usbtest" with one argument: numeric parameter representing
> the file descriptor (e.g. "./usbtest 7"). The question is should pcscd
> be extended with an argument that it would use?

On Android it may be possible to start pcscd only when a smart card
reader is connected.
So the device file descriptor could be a new pcscd argument.

On a desktop, pcscd is started when the application calls
SCardEstablishContext()
See https://ludovicrousseau.blogspot.com/2011/11/pcscd-auto-start-using-systemd.html

So pcscd may be already running when a new smart card reader is
connected and need to be added.
We must find a way to transfer the file handle to a running pcscd.

I guess Android does not use systemd. So the auto start of pcscd is
not possible on Android.

One solution would be to split pcscd in two processes:
- one process H (for hotplug) is in charge of hotplug and opening the
device (on linux)
- one process P (for pcscd) is doing the other jobs of pcscd (resource
manager between applications and readers)

The interprocess communication between H and P could be reused on
Android to transmit the new reader file handle to P.
One benefit is that P does not need to be run as root. It could be
process with low privileges.
It could help solve "Use systemd to restrict pcscd rights"
https://salsa.debian.org/rousseau/PCSC/-/issues/10

> Also, if you have an idea on how could I test that on a regular desktop
> Linux distribution it would be super-helpful as debugging it on a phone
> is really inconvenient.
>
> So: sorry for the delays but I can't currently spend the amount of time
> I would like to on this :(

No problem.
Take your time.

I understand the task is more complex than I initially thought.

Bye

-- 
 Dr. Ludovic Rousseau


From ludovic.rousseau at gmail.com  Sat Jun 11 02:10:34 2022
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Sat, 11 Jun 2022 11:10:34 +0200
Subject: [Pcsclite-muscle] New version of pcsc-lite: 1.9.8
Message-ID: <CAGstE8D+i9W9rjOewyY2uY_UxO0Zkh7ujCpbigmadM3OZEpFgw@mail.gmail.com>

Hello,

I just released a new version of pcsc-lite 1.9.8.

Changes:
1.9.8: Ludovic Rousseau
11 June 2022
- Install install_spy.sh & uninstall_spy.sh scripts in docdir
- SCardTransmit(): do not fail if receive buffer is "too large"
- SCardControl(): do not fail if receive buffer is "too large"
- fix some memory leaks on shutdown
- use a better random number generator
- Some other minor improvements

https://ludovicrousseau.blogspot.com/2022/06/new-version-of-pcsc-lite-198.html
https://pcsclite.apdu.fr/
https://github.com/LudovicRousseau/PCSC
https://salsa.debian.org/rousseau/PCSC

-- 
 Dr. Ludovic Rousseau


