How to signal smart card activity at the PC/SC level? Using D-Bus? HAL?

[Ludovic Rousseau]

Hello,

I am the maintainer of pcsc-lite [1] a middleware to access smart
cards and smart cards readers.
I am really new to D-Bus and HAL.

Someone asked for an applet that would indicate if a card activity is
ongoing or not. The idea is to have the equivalent of a smart card
reader blinking LED but in a gnome applet. The idea is nice. Some of
my readers do not blink the LED when an APDU is exchanged so it is not
easy to know if something is happening. In general I look at the pcscd
debug logs but a Gnome applet would be nicer/more integrated.

My question is: what mechanism to use to convey the information?
I was thinking of using D-Bus and also provide other information like
reader insertion/removal, card insertion/removal. And then card
communication status.

I need a one-way only event mechanism to signal events. Maybe D-Bus is
too complex and HAL is the correct answer to my problem?

Is D-Bus a good enough mechanism for that? Or should I use something
else? Is HAL more appropriate?
Any comment on this idea?

This may be related to the smart_card_reader HAL name space proposed
(and accepted) in [2].

Thanks,

[1] http://pcsclite.alioth.debian.org/
[2] http://bugs.freedesktop.org/show_bug.cgi?id=19663

--
 Dr. Ludovic Rousseau
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Stanislav Brabec]

Ludovic Rousseau wrote:

> Someone asked for an applet that would indicate if a card activity is
> ongoing or not. The idea is to have the equivalent of a smart card
> reader blinking LED but in a gnome applet. The idea is nice. Some of
> my readers do not blink the LED when an APDU is exchanged so it is not
> easy to know if something is happening. In general I look at the pcscd
> debug logs but a Gnome applet would be nicer/more integrated.
>
> My question is: what mechanism to use to convey the information?
> I was thinking of using D-Bus and also provide other information like
> reader insertion/removal, card insertion/removal. And then card
> communication status.
>
> I need a one-way only event mechanism to signal events. Maybe D-Bus is
> too complex and HAL is the correct answer to my problem?
>
> Is D-Bus a good enough mechanism for that? Or should I use something
> else? Is HAL more appropriate?
> Any comment on this idea?

D-Bus is a good generic mechanism to transport signals from the daemon
(running as root) to user space and vice versa without providing access
permissions to the device node. For an uni-directional code you can use
minimalistic signalling code (based on dbus-send or similar utility).

In the applet you can use dbus-1-glib bindings to hide all complications
of the main event loop implementation.

D-Bus destination "org.debian.alioth.pcsclite" is your playground to
start with.

You can also signal the card activity, but DBus is not optimized for
high activity, so you probably may want to delay Inactivate signal a bit
to prevent sending Active/Inactive signals say thousands times per
second.

> This may be related to the smart_card_reader HAL name space proposed
> (and accepted) in [2].

Technically, it is possible (and I was thinking about it) to extend HAL
with a new key that indicates card presence or a whole new UDI of
"SmartCard" category.

But [2] is one of the last new features accepted to hal before HAL
become deprecated, so you probably should not use HAL. If it will help
to you, you can use new technologies like libudev, DeviceKit or so.
If kernel creates no signal for card insertion/removal, you probably
don't want to use them.

As well as I remember the discussion on the opensc-list some time ago,
detection of smart card insert/removal require support in the hardware
or polling.

> [2] http://bugs.freedesktop.org/show_bug.cgi?id=19663

--
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbrabec@...
Lihovarská 1060/12           tel: [phone]
190 00 Praha 9                                  fax: [phone]
Czech Republic                                    http://www.suse.cz/

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Stanislav Brabec]

Stanislav Brabec wrote:
> Ludovic Rousseau wrote:

> > I need a one-way only event mechanism to signal events. Maybe D-Bus is
> > too complex and HAL is the correct answer to my problem?

> D-Bus is a good generic mechanism to transport signals from the daemon
> (running as root) to user space and vice versa without providing access
> permissions to the device node. For an uni-directional code you can use
> minimalistic signalling code (based on dbus-send or similar utility).

Thinking about it again, you need a bi-directional communication,
otherwise you will not be able to get information about an initial state
when applet starts. So you have to use main loop, pselect() or threads.

Here is an example of things that the daemon will provide at

interface: org.debian.alioth.pcsclite
path: /org/debian/alioth/pcsclite/reader0/slot0

signal: CardPresence
Signal sends DBUS_TYPE_BOOLEAN

method: GetCardPresence
Method gets no argument (just a path) and returns DBUS_TYPE_BOOLEAN.


The same may be used with CardActive, or you may use say DBUS_TYPE_BYTE
prototyped as enum {empty, present, active}.

--
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbrabec@...
Lihovarská 1060/12           tel: [phone]
190 00 Praha 9                                  fax: [phone]
Czech Republic                                    http://www.suse.cz/

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Bastien Nocera]

On Thu, 2009-08-27 at 14:51 +0200, Ludovic Rousseau wrote:

> Hello,
>
> I am the maintainer of pcsc-lite [1] a middleware to access smart
> cards and smart cards readers.
> I am really new to D-Bus and HAL.
>
> Someone asked for an applet that would indicate if a card activity is
> ongoing or not. The idea is to have the equivalent of a smart card
> reader blinking LED but in a gnome applet. The idea is nice. Some of
> my readers do not blink the LED when an APDU is exchanged so it is not
> easy to know if something is happening. In general I look at the pcscd
> debug logs but a Gnome applet would be nicer/more integrated.
>
> My question is: what mechanism to use to convey the information?
> I was thinking of using D-Bus and also provide other information like
> reader insertion/removal, card insertion/removal. And then card
> communication status.
>
> I need a one-way only event mechanism to signal events. Maybe D-Bus is
> too complex and HAL is the correct answer to my problem?
>
> Is D-Bus a good enough mechanism for that? Or should I use something
> else? Is HAL more appropriate?
> Any comment on this idea?
>
> This may be related to the smart_card_reader HAL name space proposed
> (and accepted) in [2].

It would be great if pcsc-lite could behave more like other daemons that
handle hardware:
- D-Bus interface for enumeration of devices, and device properties
- startup through udev (a-la bluetoothd), or when an application calls
one of its function (if usable even without hardware plugged in, as in
fprintd [1])

We wouldn't have to start the daemon on boot, and users that don't have
the hardware wouldn't have the burden of the daemon running in the
background.

Cheers

[1]: This is the documentation for the manager object in fprintd:
http://people.fedoraproject.org/~hadess/fprintd/docs/Manager.html

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Ludovic Rousseau]

2009/9/1 Bastien Nocera <hadess@...>:

> On Thu, 2009-08-27 at 14:51 +0200, Ludovic Rousseau wrote:
>> Hello,
>>
>> I am the maintainer of pcsc-lite [1] a middleware to access smart
>> cards and smart cards readers.
>> I am really new to D-Bus and HAL.
>>
>> Someone asked for an applet that would indicate if a card activity is
>> ongoing or not. The idea is to have the equivalent of a smart card
>> reader blinking LED but in a gnome applet. The idea is nice. Some of
>> my readers do not blink the LED when an APDU is exchanged so it is not
>> easy to know if something is happening. In general I look at the pcscd
>> debug logs but a Gnome applet would be nicer/more integrated.
>>
>> My question is: what mechanism to use to convey the information?
>> I was thinking of using D-Bus and also provide other information like
>> reader insertion/removal, card insertion/removal. And then card
>> communication status.
>>
>> I need a one-way only event mechanism to signal events. Maybe D-Bus is
>> too complex and HAL is the correct answer to my problem?
>>
>> Is D-Bus a good enough mechanism for that? Or should I use something
>> else? Is HAL more appropriate?
>> Any comment on this idea?
>>
>> This may be related to the smart_card_reader HAL name space proposed
>> (and accepted) in [2].
>
> It would be great if pcsc-lite could behave more like other daemons that
> handle hardware:
> - D-Bus interface for enumeration of devices, and device properties

The idea is that a D-Bus application could get information from
pcsc-lite? Or the other way around, pcscd using D-Bus to get hardware
information?

> - startup through udev (a-la bluetoothd), or when an application calls
> one of its function (if usable even without hardware plugged in, as in
> fprintd [1])

This feature is on the TODO list.
http://svn.debian.org/wsvn/pcsclite/trunk/PCSC/TODO

Thanks

--
 Dr. Ludovic Rousseau
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg