I guess you need to start openct init script.
On 1/23/09, Stefan X wrote:
> Hi!
> Right now I tried the current German health card (eGK) with opensc but
> it failed unfortunately. I am not a developer and have no experience
> with OpenSC. Nevertheless I would like to support opensc somehow to
On 1/23/09, Ludovic Rousseau wrote:
> Good idea. I already started to add support for Mac OS X. But
> compilation of OpenSSL fails. It should not be a cross-compilation on
> Mac OS X.
Why?
Which host do you use? I want to try this myself.
Maybe open a bug with OpenSSL developers as cross compi
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
2009/1/23 Alon Bar-Lev :
> On 1/23/09, Ludovic Rousseau wrote:
>> I don't think mingw exists for Mac OS X. Do you plan to cross-compile
>> for Mac OS X from GNU/Linux?
>>
>> Mac OS X should be able to use autoconf/automake as on any other Unix
>> system. I don't see a need for cross-compile her
Hi!
Right now I tried the current German health card (eGK) with opensc but
it failed unfortunately. I am not a developer and have no experience
with OpenSC. Nevertheless I would like to support opensc somehow to get
this card working. If you let me know what to do or where I can read how
to test th
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 Friday, January 23, 2009 12:38:54 PM +0100 Andreas Jellinghaus
wrote:
> hmm. I always wondered if loading binary only pkcs#11 libraries
> via pam_p11/pkcs11 into login and gdm/kdm would be ok.
Loading? Yes, always -- despite the FSF's best efforts to force people to
use only open-source
On 1/23/09, Ludovic Rousseau wrote:
> 2009/1/23 Alon Bar-Lev :
>
> > BTW: I asked in the past... Can you please try to see if the build [1]
> > project can also be useful for you? I don't think we should maintain
> > both...
> >
> > It is good also as none cross compile.
> >
> > [1] http://w
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
2009/1/23 Alon Bar-Lev :
> BTW: I asked in the past... Can you please try to see if the build [1]
> project can also be useful for you? I don't think we should maintain
> both...
>
> It is good also as none cross compile.
>
> [1] http://www.opensc-project.org/build
I don't think mingw exists for M
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
Am Freitag 23 Januar 2009 16:46:31 schrieb Jean-Pierre Szikora:
> Undefined symbols:
>"_PKCS11_CTX_init_args", referenced from:
>_pkcs11_init in engine_pkcs11_la-engine_pkcs11.o
> ld: symbol(s) not found
>
> Complete transcript in attachment.
why the leading underscore?
the symbol is i
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
BTW: I asked in the past... Can you please try to see if the build [1]
project can also be useful for you? I don't think we should maintain
both...
It is good also as none cross compile.
[1] http://www.opensc-project.org/build
On 1/23/09, Alon Bar-Lev wrote:
> On 1/23/09, Jean-Pierre Szikora w
On 1/23/09, Jean-Pierre Szikora wrote:
> I compiled (on MacIntel) without problems this opensc and libp11 0.2.4.
> But engine 0.1.5 compilation fails:
Do you use last released versions of engine_pkcs11 nor libp11?
Had it worked before? I remembered it was OK for you.
Anyway... What I need is a
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
On 1/23/09, Andreas Jellinghaus wrote:
> Am Freitag 23 Januar 2009 14:48:23 schrieb Alon Bar-Lev:
> > Works for me :)
>
> thanks for reporting!
>
> could you test the privdata fix?
> if so, with which cards?
Yes.
Already reported... asepcos works OK, I even did not had to
reinitialize the tok
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_
Am Freitag 23 Januar 2009 14:48:23 schrieb Alon Bar-Lev:
> Works for me :)
thanks for reporting!
could you test the privdata fix?
if so, with which cards?
Thanks, Andreas
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.op
Am Freitag 23 Januar 2009 14:56:54 schrieb Alon Bar-Lev:
> On 1/23/09, Andreas Jellinghaus wrote:
> > Am Freitag 23 Januar 2009 08:48:53 schrieb Alon Bar-Lev:
> > > So the rules of having a plugin to GPL or LGPL should be the same.
> >
> > absolutely not.
> >
> > LGPL is "make changes to my code
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
On 1/23/09, Andreas Jellinghaus wrote:
> Am Freitag 23 Januar 2009 08:48:53 schrieb Alon Bar-Lev:
>
> > So the rules of having a plugin to GPL or LGPL should be the same.
>
>
> absolutely not.
>
> LGPL is "make changes to my code open source under LGPL, but
> any code you write on your own is yo
Works for me :)
On 1/23/09, Andreas Jellinghaus wrote:
> here is a new snapshot with the latest code:
>
> http://www.opensc-project.org/files/opensc/snapshots/opensc-0.11.6-svn-
> r3639.tar.gz
>
> please give it a try and let me know if it works, or what is wrong with it.
>
>
> Thanks, Andrea
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
here is a new snapshot with the latest code:
http://www.opensc-project.org/files/opensc/snapshots/opensc-0.11.6-svn-
r3639.tar.gz
please give it a try and let me know if it works, or what is wrong with it.
Thanks, Andreas
___
opensc-devel mailing list
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
Hi,
does opensc in the current svn version still work for you?
can you check if the privdata fix works for the cards you
have?
note: with older versions of opensc you can download
private data with opensc-explorer without entering
the pin, even though it was stored with the private
maker. it woul
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
Am Freitag 23 Januar 2009 08:48:53 schrieb Alon Bar-Lev:
> So the rules of having a plugin to GPL or LGPL should be the same.
absolutely not.
LGPL is "make changes to my code open source under LGPL, but
any code you write on your own is yours to keep" from my point
of view. Thus keeping totaly ne
On 1/23/09, Ludovic Rousseau wrote:
> 2009/1/23 Alon Bar-Lev :
>
> > 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
2009/1/23 Alon Bar-Lev :
> 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
Set default to hide as we discussed.
On 1/19/09, Alon Bar-Lev wrote:
> On 1/19/09, Martin Paljak wrote:
>
> > On Mon, Jan 19, 2009 at 3:00 PM, Alon Bar-Lev wrote:
> > >> Tried it as well. hide_empty_tokens only matters for PKCS#15-init
> > >> compatible cards and does not apply to read-on
Hi,
I changed the default to true and renamed the option to plug_and_play,
as it is the only feature it controls.
Alon.
On 1/20/09, Alon Bar-Lev wrote:
> Hello,
>
> I don't understand.
> OpenSC PKCS#11 modules *ALWAYS* allocate specific number of virtual slots.
> The plug&play just link betw
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_
39 matches
Mail list logo
