Andreas Jellinghaus wrote:
> Am Mittwoch 28 Januar 2009 19:02:39 schrieb Stanislav Brabec:
> > In case of Smart Cards, it might be GID writability for "scard" group,
> > allowing to run smart card daemon without root privileges.
>
> if pcscd or openct should run as non-root, then there should be:
Andreas Jellinghaus wrote:
> Am Mittwoch 28 Januar 2009 19:30:52 schrieb Stanislav Brabec:
> > How to name the main category "smart_card_reader or crypto_token"?
>
> I think it is easer to explain, that a usb crypto token is a device consisting
> of a reduced smart card reader and a fixed build in
On 1/29/09, Andreas Jellinghaus wrote:
> Am Mittwoch 28 Januar 2009 19:02:39 schrieb Stanislav Brabec:
>
> > In case of Smart Cards, it might be GID writability for "scard" group,
> > allowing to run smart card daemon without root privileges.
>
>
> if pcscd or openct should run as non-root, then
Am Mittwoch 28 Januar 2009 19:05:08 schrieb Alon Bar-Lev:
> Running software as root is the worst solution. Especially security
> centric software.
not a good solution, but not the worst. remember old linux/unix systems
with a bin user and group, and all binaries owned by them? that was
worse. cre
Am Mittwoch 28 Januar 2009 19:02:39 schrieb Stanislav Brabec:
> In case of Smart Cards, it might be GID writability for "scard" group,
> allowing to run smart card daemon without root privileges.
if pcscd or openct should run as non-root, then there should be:
* one way how openct/pcscd can access
Am Mittwoch 28 Januar 2009 19:30:52 schrieb Stanislav Brabec:
> How to name the main category "smart_card_reader or crypto_token"?
I think it is easer to explain, that a usb crypto token is a device consisting
of a reduced smart card reader and a fixed build in smart card. I guess
this is quite cl
--On Thursday, January 29, 2009 03:36:42 AM +0100 Peter Stuge
wrote:
> Jeffrey Hutzelman wrote:
>> the USB device is entirely in the card.
>
> They are nice. I was building my own expresscard egate adapter for a
> while there.
That sounds like a useful item, and hopefully not too tricky.
Too ba
Jeffrey Hutzelman wrote:
> the USB device is entirely in the card.
They are nice. I was building my own expresscard egate adapter for a
while there.
//Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.o
--On Thursday, January 29, 2009 02:58:53 AM +0100 Peter Stuge
wrote:
> Jeffrey Hutzelman wrote:
>> Something like the Reflex "reader" which is really just an egate
>> adapter.
>
> I don't think there is a USB device until the egate is inserted.
That's correct. The adapter is just a very funny
Jeffrey Hutzelman wrote:
> Something like the Reflex "reader" which is really just an egate
> adapter.
I don't think there is a USB device until the egate is inserted.
//Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://w
Andreas Jellinghaus wrote:
> > We need a "category" string that covers both and use it for both,
> > otherwise we will have problems in defining generic rules (especially in
> > case, when we know, that it is ISO 7816 device, but don't know, which
> > one).
> >
> > Possibilities:
> > iso7816 = smar
On 1/28/09, Andreas Jellinghaus wrote:
> someone has a group "usb"? ouch. I don't like this proposal.
Gentoo has.
> people might think "lets add a user to that group, like we do with audio
> and video, so people can use usb devices". if then this would be implemented
> like alon suggested, a
Andreas Jellinghaus wrote:
> Am Mittwoch 28 Januar 2009 18:06:33 schrieb Alon Bar-Lev:
> > On 1/28/09, Andreas Jellinghaus wrote:
> > > > - Define policy for ACL (see freedesktop Bugzilla)
> > >
> > > root,root 0600 is fine with me. distributions could create some system
> > > account, and use th
Am Mittwoch 28 Januar 2009 18:06:33 schrieb Alon Bar-Lev:
> On 1/28/09, Andreas Jellinghaus wrote:
> > > - Define policy for ACL (see freedesktop Bugzilla)
> >
> > root,root 0600 is fine with me. distributions could create some system
> > account, and use that system account for such usb devices
On 1/28/09, Andreas Jellinghaus wrote:
> > - Define policy for ACL (see freedesktop Bugzilla)
>
> root,root 0600 is fine with me. distributions could create some system
> account,
> and use that system account for such usb devices and run pcscd and openct
> under these accounts (if that works
> We need a "category" string that covers both and use it for both,
> otherwise we will have problems in defining generic rules (especially in
> case, when we know, that it is ISO 7816 device, but don't know, which
> one).
>
> Possibilities:
> iso7816 = smart_chip*
ok, but then please name it "sma
--On Wednesday, January 28, 2009 03:41:49 PM +0100 Ludovic Rousseau
wrote:
(mostly I'm agreeing with Ludovic here and adding a few comments of my own)
> 2009/1/28 Stanislav Brabec :
>> We need a "category" string that covers both and use it for both,
>> otherwise we will have problems in defin
2009/1/28 Stanislav Brabec :
> We need a "category" string that covers both and use it for both,
> otherwise we will have problems in defining generic rules (especially in
> case, when we know, that it is ISO 7816 device, but don't know, which
> one).
>
> Possibilities:
> iso7816 = smart_chip*
Ple
Andreas Jellinghaus wrote:
> Am Dienstag 27 Januar 2009 19:14:31 schrieb Stanislav Brabec:
> > Ludovic Rousseau wrote:
> > > 2009/1/23 Stanislav Brabec :
> > > > I don't know, whether multi-slot devices use more USB devices, more USB
> > > > interfaces or only one interface and multi-slot protocol.
--On Tuesday, January 27, 2009 11:01:15 PM +0100 Ludovic Rousseau
wrote:
> 2009/1/27 Stanislav Brabec :
>> It is possible to detect form factor (credit card size, SIM size)?
>
> No. This information is not stored in any USB descriptor I know.
You certainly can't tell in all cases. For example,
Am Dienstag 27 Januar 2009 19:14:31 schrieb Stanislav Brabec:
> Ludovic Rousseau wrote:
> > 2009/1/23 Stanislav Brabec :
> > > I don't know, whether multi-slot devices use more USB devices, more USB
> > > interfaces or only one interface and multi-slot protocol.
> >
> > A multi-slot reader is just
2009/1/27 Stanislav Brabec :
> It is possible to detect form factor (credit card size, SIM size)?
No. This information is not stored in any USB descriptor I know.
> Is it the same way that can be used to detect contact less reader?
You can't detect a contactless reader from the USB descriptor. I
Ludovic Rousseau wrote:
> 2009/1/23 Stanislav Brabec :
> > I don't know, whether multi-slot devices use more USB devices, more USB
> > interfaces or only one interface and multi-slot protocol.
>
> A multi-slot reader is just one USB device. The only difference is the
> value of the bMaxSlotIndex
2009/1/23 Stanislav Brabec :
> I don't know, whether multi-slot devices use more USB devices, more USB
> interfaces or only one interface and multi-slot protocol.
A multi-slot reader is just one USB device. The only difference is the
value of the bMaxSlotIndex field in the CCID descriptor.
I don
Andreas Jellinghaus wrote:
> before I forget:
> we also have at least one card reader with wireless interface.
> it supports iso 14433A and B and mifare protocols, if I'm not mistaken.
> the code to use it is librfid.
>
> I would prefer not to use the "rfid" name in any way, since has become a
> g
before I forget:
we also have at least one card reader with wireless interface.
it supports iso 14433A and B and mifare protocols, if I'm not mistaken.
the code to use it is librfid.
I would prefer not to use the "rfid" name in any way, since has become a
generic word for very different technologi
On 1/23/09, Andreas Jellinghaus wrote:
> Am Freitag 23 Januar 2009 16:15:39 schrieb Alon Bar-Lev:
>
> > > Plus:
> > > - no udev event is generated when the device is removed
> >
> > There is, I sent you.
> > Hal get this from somewhere...
>
>
> hal remembers, udev does not. thus udev only kn
Am Freitag 23 Januar 2009 16:15:39 schrieb Alon Bar-Lev:
> > Plus:
> > - no udev event is generated when the device is removed
>
> There is, I sent you.
> Hal get this from somewhere...
hal remembers, udev does not. thus udev only knows that some usb
device is gone, but does not remember e.g. ve
(joining two sub-threads)
Andreas Jellinghaus wrote:
> new topic: usb crypto tokens
> I think we should have both "smart_card_reader" and "usb_crypto_token"
> for those token with internal smart cards (e.g. aladdin etoken pro and
> friends). it could confuse the users if we say they are smart car
Andreas Jellinghaus wrote:
> 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, wil
Ludovic Rousseau wrote:
> 2009/1/23 Stanislav Brabec :
> > A separately maintained package would be another possible way to
> > distribute FDI files: Scan all available driver packages, create a list
> > of all known readers, their USB/PCI ids and capabilities (class, card
> > format,...).
>
> I
On 1/23/09, Ludovic Rousseau wrote:
> > anyway, old stories, long closed. using hald is supported upstream and
> > easier, thus it is the recommend way from my point of view.
>
>
> I have the exact same (frustrating) experience with udev and pcsc-lite.
>
> Plus:
> - no udev event is generated
2009/1/23 Andreas Jellinghaus :
> new topic: usb crypto tokens
> I think we should have both "smart_card_reader" and "usb_crypto_token"
> for those token with internal smart cards (e.g. aladdin etoken pro and
> friends). it could confuse the users if we say they are smart card readers.
Could "usb_
2009/1/23 Stanislav Brabec :
> Andreas Jellinghaus píše v Pá 23. 01. 2009 v 13:27 +0100:
>> Am Freitag 23 Januar 2009 12:59:57 schrieb Stanislav Brabec:
>> > HAL documentation recommends to discriminate between three types of FDI
>> > files:
>> > - preprobe: Actions before hal starts to identify th
Am Freitag 23 Januar 2009 14:40:18 schrieb Stanislav Brabec:
> Well, maybe "capabilities" is not a right place to add this keyword, but
> the idea remains.
agree.
> > with hal, do we need to make sure only either openct fdi file or ccid fdi
> > file is installed? or how can you manage, whether so
Andreas Jellinghaus píše v Pá 23. 01. 2009 v 13:27 +0100:
> Am Freitag 23 Januar 2009 12:59:57 schrieb Stanislav Brabec:
> > HAL documentation recommends to discriminate between three types of FDI
> > files:
> > - preprobe: Actions before hal starts to identify the device
> > - information: Collect
Am Freitag 23 Januar 2009 12:59:57 schrieb Stanislav Brabec:
> HAL documentation recommends to discriminate between three types of FDI
> files:
> - preprobe: Actions before hal starts to identify the device
> - information: Collecting information about the device
> - policy: Perform actions
>
> Cur
Andreas Jellinghaus wrote:
> > 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?
HAL documentation recommends to discriminate between three types o
2009/1/22 Andreas Jellinghaus :
> 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
Hello,
I have no objection to report more information about the smart card
reader at the HAL interface. But as you said we should be careful of
the names we use.
2009/1/22 Stanislav Brabec :
> Here is a short example, what I intend to do:
>
>
>
>
>
>
>
> smart_card_
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
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
__
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
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
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
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".
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
--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
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
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
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
57 matches
Mail list logo
