On 1/23/09, Andreas Jellinghaus wrote:
> > It cannot be unless we explicitly specify some exceptions in OpenSC
> > license. A plugin for LGPL should be also GPLed.
> > Read [1] and on.
>
>
> opensc is not under GPL.
GPL and LGPL are the same, except of that none GPLed application can
be linked
On 1/23/09, Andreas Jellinghaus wrote:
> > 3. pcscd must run as root... A none root mode may be supported but
> > never implemented.
> forgive me, but usb control transfer ioctl can only be done as root I thought?
> thus anyone trying these on a usb device needs root? or is write access to
> th
Am Donnerstag 22 Januar 2009 19:34:10 schrieb Alon Bar-Lev:
> On 1/22/09, Jeffrey Hutzelman wrote:
> > provide source. I think it's also important to consider cases where
> > there _is_ an open-source driver, but with a GPL-incompatible license.
I'm not aware of any open-source driver for
opensc
Am Donnerstag 22 Januar 2009 18:49:07 schrieb Alon Bar-Lev:
> > I think we should discuss this scenario:
> > is it ok if someone uses opensc, changes it as he likes, and published
> > the resulting code and binaries - with one file only published as *.o
> > (his new card driver)? I guess that cap
Am Freitag 23 Januar 2009 01:49:05 schrieb Peter Stuge:
> Andreas Jellinghaus wrote:
> > if anyone wants to walk into the opposite direction, write a daemon
> > that monitors usb and then acts on any change, that is fine with me
> > - I think pcscd does exactly that? not sure.
>
> Implementation sh
Am Freitag 23 Januar 2009 06:51:13 schrieb Alon Bar-Lev:
> On 1/22/09, Jeffrey Hutzelman wrote:
> > How do you propose for USB device drivers to talk to their devices, if
> > not using libusb? Remember, we'd like to be portable here; the whole
> > world's not Linux.
>
> openct does not use libus
> 3. pcscd must run as root... A none root mode may be supported but
> never implemented.
forgive me, but usb control transfer ioctl can only be done as root I thought?
thus anyone trying these on a usb device needs root? or is write access to
the device enough?
> 4. Due to the threading limitati
Sorry Peter,
I have no clue how you make the connection from usb interrupt
mode to hal.
from my point of view udev is unstable and changes in udev
broke the udev/openct setup several times. the udev/hotplug/linux-usb
folks recommend to use hal instead, which so far is working fine.
so why not use
On 1/22/09, Jeffrey Hutzelman wrote:
> How do you propose for USB device drivers to talk to their devices, if not
> using libusb? Remember, we'd like to be portable here; the whole world's
> not Linux.
openct does not use libusb for communicating with usb even before I
know it exists... :)
This
Andreas Jellinghaus wrote:
> if anyone wants to walk into the opposite direction, write a daemon
> that monitors usb and then acts on any change, that is fine with me
> - I think pcscd does exactly that? not sure.
Implementation should be simple at least for Linux.
//Peter
__
Stanislav Brabec wrote:
> On the link level, USB interrupt mode is based on periodical
> re-submitting of the interrupt URB.
Yeah. USB devices can be put to sleep and signal wakeup too.
Seems our opinion is that HAL is bloat and bad for life.
Your situation does not align with this.
Obviously y
Martin Paljak wrote:
> AFAIK we don't support any wireless things.
librfid [http://openmrtd.org/] can use OpenCT for wireless things.
//Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/list
Am Donnerstag 22 Januar 2009 18:57:19 schrieb Alon Bar-Lev:
> On 1/22/09, Andreas Jellinghaus wrote:
> > using udev was a huge pain for many years, everytime I thought "now it
> > works", a few months later openct didn't work with the new udev. I'm
> > sick of that pain, and since the udev/hotpl
> information: Identify selected devices.
> info.category = 'smart_card_reader'
> info.capabilities = { 'openct' }
openct or some other software should not matter IMO, why make it a capability?
> Good idea! But iso7816 could make it more cryptic to ordinary users.
right. stick with "smart_card_r
--On Thursday, January 22, 2009 06:50:34 PM +0100 Andreas Jellinghaus
wrote:
> more complex operations such as "upload new firmware
> to card reader" will most propably never work with pcscd (guessing only,
> I'm no expert here).
I think that's going to depend on the reader driver. There cert
--On Thursday, January 22, 2009 08:49:33 PM +0200 Alon Bar-Lev
wrote:
> Poll the reader to detect card insert.
Yeah, that's still a problem, and certainly one I'd like to see fixed.
It's also per-driver, and I'm not sure it even _can_ be fixed for all kinds
of devices.
>> > 5. The udev sup
Andreas Jellinghaus wrote:
> openct already has a fci file, adding some
> information into it so gui tools can identify
> the result is not a bad idea I guess.
It's my plan to start with this file. This file uses "smart_card_reader"
for category. HAL specification recommends to use two FDI files i
On 1/22/09, Jeffrey Hutzelman wrote:
> --On Thursday, January 22, 2009 08:14:20 PM +0200 Alon Bar-Lev
> wrote:
>
>
> > Well, Ludovic knows my arguments...
> >
>
>
> > 4. Due to the threading limitation of libusb or kenrel pcscd polls
> > readers every 2 seconds which waste CPU and power resources
--On Thursday, January 22, 2009 08:14:20 PM +0200 Alon Bar-Lev
wrote:
> Well, Ludovic knows my arguments...
> 4. Due to the threading limitation of libusb or kenrel pcscd polls
> readers every 2 seconds which waste CPU and power resources.
Only if you have reader drivers which require this. I
On 1/22/09, Jeffrey Hutzelman wrote:
> provide source. I think it's also important to consider cases where there
> _is_ an open-source driver, but with a GPL-incompatible license.
It cannot be unless we explicitly specify some exceptions in OpenSC license.
A plugin for LGPL should be also GPLed.
--On Thursday, January 22, 2009 06:24:58 PM +0100 Andreas Jellinghaus
wrote:
> my point of view is:
> there is not a single external driver that I'm aware off.
> thus we could remove the whole code for allowing external
> loadable drivers, as there are none, and that would simplify
> the code.
Andreas Jellinghaus wrote:
> Am Donnerstag 22 Januar 2009 15:54:07 schrieb Stanislav Brabec:
> > > But why do you need to configure PolicyKit? What is the problem
> > > PolicyKit is trying to solve?
> >
> > Grating access to users physically present at the computer.
> > It uses standard UNIX ACL, s
On 1/22/09, Jeffrey Hutzelman wrote:
> >
> > > Yes, udev supports it as well. But most vendors prefer HAL for this
> > > purpose nowadays.
> > >
> >
> > vendors? You mean Novell, right?
> >
>
> Most of the major Linuxes, both commercial and otherwise.
> I believe Sun is also going down this pat
adding a few "info.capability" to the fci files is fine with me.
the other side is: how these are evaluated.
if I have a machine, where both gui access as well console
login need the smart card reader, then giving exclusive rights
to the one logged in, will break console login?
I understand the
On 1/22/09, Andreas Jellinghaus wrote:
> using udev was a huge pain for many years, everytime I thought "now it
> works", a few months later openct didn't work with the new udev. I'm sick
> of that pain, and since the udev/hotplug/linux-usb folks tell us to use hal,
> and hal seems to work, I
Am Donnerstag 22 Januar 2009 15:54:07 schrieb Stanislav Brabec:
> > But why do you need to configure PolicyKit? What is the problem
> > PolicyKit is trying to solve?
>
> Grating access to users physically present at the computer.
> It uses standard UNIX ACL, so it can apply to both device nodes and
openct already has a fci file, adding some
information into it so gui tools can identify
the result is not a bad idea I guess.
please don't use "card_reader", we already have trouble with people
only knowing comptact flash / smart media cards / ... and being confused
by what we call "smart card".
On 1/22/09, Andreas Jellinghaus wrote:
> the only one using the internal api is openssh, and it can be ported
> to pkcs#11 - alon has done that, but it is a part of a huge change that
> is unlikely to find many adopters (my personal guess - I think people
> like that ssh is very easy and simpl
Am Donnerstag 22 Januar 2009 08:08:43 schrieb Alon Bar-Lev:
> On 1/22/09, Marc Rios Valles wrote:
> > Hi,
> >
> > I have been making some test and if I don't put the two functions in
> > libopensc.exports I get a segfault accessing to them...
>
> But these were prototyped at internal.h and inter
Jeffrey Hutzelman wrote:
> > PolicyKit may be useful for pcsc-lite/openct as well, to block remote
> > users access to daemon.
>
> I'm not sure how you intend to do that, or even that it's a good idea.
You can apply policy on /var/run/pcscd/pcscd.comm. (Not tested yet.)
> In
> fact, I'm pretty
Jeffrey Hutzelman wrote:
> >> > HAL recognizes Smart Card readers as unknown USB devices
> >> Why is that a problem? Why do you need HAL to know about smart card
> >> readers?
> > HAL detects correctly music players, scanners, fingerprint readers,
> > UPSes (well, just only HID). Why Smart Cards
2009/1/22 Stanislav Brabec :
> Ludovic Rousseau wrote:
>> 2009/1/22 Stanislav Brabec :
>
>> > HAL recognizes Smart Card readers as unknown USB devices
>>
>> Why is that a problem? Why do you need HAL to know about smart card readers?
>
> HAL detects correctly music players, scanners, fingerprint re
Alon Bar-Lev wrote:
> On 1/22/09, Stanislav Brabec wrote:
> > USB peripheral cannot initiate transfer, so USB requires some type of
> > polling by design.
>
> As far as I know and tried USB support interrupt mode, checkout the
> openct trunk ccid driver.
On the link level, USB interrupt mode i
--On Thursday, January 22, 2009 03:54:07 PM +0100 Stanislav Brabec
wrote:
> Ludovic Rousseau wrote:
>> 2009/1/22 Stanislav Brabec :
>
>> > HAL recognizes Smart Card readers as unknown USB devices
>>
>> Why is that a problem? Why do you need HAL to know about smart card
>> readers?
>
> HAL detect
--On Thursday, January 22, 2009 01:18:44 PM +0100 Stanislav Brabec
wrote:
>> I cannot
>> imagine any vendor shipping policy that would allow ordinary users
>> direct access to smartcard devices.
>
> openSUSE has to do it, at least for selected readers, otherwise users of
> these applications co
--On Thursday, January 22, 2009 02:57:10 PM +0200 Alon Bar-Lev
wrote:
> On 1/22/09, Stanislav Brabec wrote:
>> Alon Bar-Lev wrote:
>> > On 1/21/09, Stanislav Brabec wrote:
>> Yes, udev supports it as well. But most vendors prefer HAL for this
>> purpose nowadays.
>
> vendors? You mean Novel
On 1/22/09, Stanislav Brabec wrote:
> USB peripheral cannot initiate transfer, so USB requires some type of
> polling by design.
As far as I know and tried USB support interrupt mode, checkout the
openct trunk ccid driver.
Alon.
___
opensc-devel mail
Ludovic Rousseau wrote:
> 2009/1/22 Stanislav Brabec :
> > HAL recognizes Smart Card readers as unknown USB devices
>
> Why is that a problem? Why do you need HAL to know about smart card readers?
HAL detects correctly music players, scanners, fingerprint readers,
UPSes (well, just only HID). Wh
Alon Bar-Lev wrote:
> On 1/22/09, Stanislav Brabec wrote:
> > Alon Bar-Lev wrote:
> > > This is why you have udev, right?
> > Yes, udev supports it as well. But most vendors prefer HAL for this
> > purpose nowadays.
> vendors? You mean Novell, right?
Not only Novell. GNOME desktop use HAL and
2009/1/22 Stanislav Brabec :
> Reading the discussion, I want to clarify the original problem and
> needed help:
>
> Primary problem:
>
> HAL recognizes Smart Card readers as unknown USB devices
Why is that a problem? Why do you need HAL to know about smart card readers?
I guess it is directly lin
On 1/22/09, Stanislav Brabec wrote:
> Alon Bar-Lev wrote:
> > On 1/21/09, Stanislav Brabec wrote:
>
>
> > > 1) There are applications, that need direct access to the reader, not
> > > using pcsc-lite (example: cyberjack utilities). That is why it should
> > > allow to access not only to pcsc
2009/1/22 Stanislav Brabec :
> Ludovic Rousseau wrote:
>> PC/SC provides a method to detect reader insertion/removal. HAL is not
>> needed here.
>
> Yes, it is. But HAL broadcasts generic device removal events. One has to
> connect to pcscd to just identify, whether unknown USB device is a Smart
>
Reading the discussion, I want to clarify the original problem and
needed help:
Primary problem:
HAL recognizes Smart Card readers as unknown USB devices
Proposal to fix:
- Add a keyword for info.category (one word for device is permitted) to
describe the device (other devices use for example
Jeffrey Hutzelman wrote:
> > 1) There are applications, that need direct access to the reader, not
> > using pcsc-lite (example: cyberjack utilities).
>
> And how do these devices know how to talk to readers? Do they have their
> own reader drivers, separate from those included with pcsc-lite o
Ludovic Rousseau wrote:
> 2009/1/21 Stanislav Brabec :
> > Alon Bar-Lev wrote:
> >> I don't understand the motivation.
> >> Why do you care if readers are accessible by all users?
> >
> > 1) There are applications, that need direct access to the reader, not
> > using pcsc-lite (example: cyberjack u
Alon Bar-Lev wrote:
> On 1/21/09, Stanislav Brabec wrote:
> > 1) There are applications, that need direct access to the reader, not
> > using pcsc-lite (example: cyberjack utilities). That is why it should
> > allow to access not only to pcsc daemon, but also to users.
>
> This is why you have
2009/1/21 Stanislav Brabec :
> Alon Bar-Lev wrote:
>> I don't understand the motivation.
>> Why do you care if readers are accessible by all users?
>
> 1) There are applications, that need direct access to the reader, not
> using pcsc-lite (example: cyberjack utilities). That is why it should
> all
47 matches
Mail list logo
