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-only PKCS#15 emulated
> >> cards.
> >
>
and true plug&play throughout the whole libopensc.
Alon.
On 1/19/09, Martin Paljak wrote:
> On Mon, Jan 19, 2009 at 3:23 PM, Alon Bar-Lev wrote:
> > I think the 2.20 should be the default, as the plug&play mode is important.
>
> Agreed.
>
> > All 2.11 applications wil
On 1/20/09, Ludovic Rousseau wrote:
> > +static int et_event(ifd_reader_t * reader, int *status, size_t
> status_size)
> > +{
> > + (void)reader;
> > + (void)status;
> > + (void)status_size;
>
> What is the code above supposed to do?
> It just looks like void code for me.
Added to export.
Thanks.
On 1/21/09, Marc Rios Valles wrote:
> Hi,
>
> I have found the problem. You are not exporting the function
> sc_get_iso7816_driver any more... I can understand why but in the file
> libopensc.exports isn't this function. Why is that?
>
> Thanks for all,
> --
> Marc
>
>
> On Wed, 2009-01-21 at 15:01 +0200, Alon Bar-Lev wrote:
> > Added to export.
> > Thanks.
> >
> > On 1/21/09, Marc Rios Valles wrote:
> > > Hi,
> > >
> > > I have found the problem. You are not exporting the f
I don't understand the motivation.
Why do you care if readers are accessible by all users?
On 1/21/09, Stanislav Brabec wrote:
> Hallo.
>
> I just filled a proposal for a new HAL (Hardware Abstraction Layer,
> http://hal.freedesktop.org/ ) category recognized by PolicyKit.
>
> Here is a propos
On 1/21/09, Stanislav Brabec wrote:
> 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: c
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 internal.h was never made public.
So whoever wrote this driver used internal f
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
&g
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
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
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
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
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 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
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
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
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
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
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
> > >> compati
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.
> >> &
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
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
>
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
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, 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
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
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...
>
>
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
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
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
...
The gentoo.config-0.9.8 is doing the conversion and never had to do
this for mingw or darwin... :)
Alon.
On 1/24/09, Ludovic Rousseau wrote:
> 2009/1/24 Alon Bar-Lev :
>
> > On 1/23/09, Ludovic Rousseau wrote:
> >> Good idea. I already started to add support for Mac OS X. B
On 1/24/09, Martin Paljak wrote:
>
> On 24.01.2009, at 8:12, Alon Bar-Lev wrote:
>
> > BTW: You should check if you need to include iconv in this environment
> > as well... I remember martin had to add it.
> >
> iconv, as well as OpenSSL are provided by OS X, so un
On 1/24/09, Ludovic Rousseau wrote:
> 2009/1/24 Alon Bar-Lev :
>
> > Now I understand what you mean.
> > The translation script between the CHOST and openssl host does not
> > support darwin.
> >
> > Can you please tell me how to map gcc -dumpmachine outpu
On 1/24/09, Ludovic Rousseau wrote:
> 2009/1/24 Alon Bar-Lev :
>
> > Please try now.
>
> Build of OpenSSL fails if I use MAKEFLAGS=-j3
> It is OK with no MAKEFLAGS.
> OpenSSL does not like parallel build?
True.
You need to use MAKEOPTS="-j3" and I don't
On 1/24/09, Ludovic Rousseau wrote:
> > So everything is working accept this?
> No idea. I don't know how to test the compiled binaries.
Oh... It should be working opensc, no? Is there a major difference
between darwin and other unixes?
Alon
___
opens
On 1/26/09, Ludovic Rousseau wrote:
> I do not want to invest more time in this build script since I do not
> use OpenSC on Mac OS X.
OK.
> trunk/image/opensc/bin$ ./opensc-tool
> dyld: Library not loaded: //lib/libopensc.2.dylib
> Referenced from:
>
> /Users/lroussea/Documents/sc/OpenSC
On 1/26/09, Ludovic Rousseau wrote:
>
> What are your supposed to do with the image?
> How are you supposed to _install_ the software?
On Windows you can provide installer with these files. For now I just
provide archive.
On Linux if you compile uclibc for initramfs you can just copy the
result
On 1/26/09, Ludovic Rousseau wrote:
> I patched the OpenSC version of src/ifd/proto-t1.c (patch attached)
Great!
Thanks you!
> THIS PATCH DOES NOT WORK. It is just a preview.
>
> Notes:
> - the t1_* functions use a "ifd_protocol_t * prot" parameter but I
> need a "t1_state_t * t1" since some
On 1/26/09, Ludovic Rousseau wrote:
> I will not commit the patch I sent. The work is not finished. What I
> propose is to commit only parts of it, the parts that integrate easily
> in OpenCT.
Great!
> The OpenCT CCID is "very" limited.
> For example I just discovered it does not negotiate th
On 1/28/09, Jeffrey Hutzelman wrote:
> > * PC/SC library is dynamic linked no longer compile time dependency.
>
>
> WHY
>
> What was wrong with using pkg-config to find the library, and then linking
> against it? This approach is broken in several ways:
>
> It assumes the pcsclite library
On 1/28/09, Jeffrey Hutzelman wrote:
> --On Wednesday, January 28, 2009 12:51:05 PM +0200 Alon Bar-Lev
> wrote:
>
>
> >
> > > It assumes the pcsclite library is in a particular location, instead of
> > > searching for it. This means it will fail to find lib
Thanks.
Applied.
On 1/28/09, Aktiv Co. Aleksey Samsonov wrote:
> Hello.
> I propose the attached patch for "Rutoken S" codes.
> Changes:
> - use PKCS#15 (not builtin PKCS#15 emulator)
> - rutoken.profile (add privdata)
> - correct using ACL
> - correct erase procedure
>
> __
CONFIG_USB_DEVICEFS
enable to test it.
Thanks,
Alon
[1] http://www.opensc-project.org/openct/changeset/1116
[2] http://www.opensc-project.org/openct/changeset/1115
On 1/28/09, Alon Bar-Lev wrote:
> Thanks.
> Applied.
>
>
> On 1/28/09, Aktiv Co. Aleksey Samsonov wrote:
> > Hello
On 1/28/09, Martin Paljak wrote:
> You could blame Apple for this, but in real life there are many such tweaks
> in OS X.
Sure I can blame apple. PC/SC is Microsoft API, the API is fixed and
apple cannot modify entry points.
>
> I don't see how adding another corner case to deal with OS X make
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
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
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
On 1/29/09, Aktiv Co. Aleksey Samsonov wrote:
> Alon Bar-Lev:
>
> > Can you please update the openct trunk so that Rutoken use the new
> > event interface?
> >
>
> OK, the updated patch is attached.
Thanks!
Alon.
___
op
Should be.
The autoconf substitute this in the Makefile, and the sysconfdir is
resolved by make.
When you run make, do you see invalid value for CPPFLAGS_OPENCT_CONF_PATH?
Alon.
On 1/29/09, Aktiv Co. Aleksey Samsonov wrote:
> Hello.
> The openct trunk revision 1127: configure.ac: Line 400:
> C
On 1/29/09, Andrey Jivsov wrote:
> I am attaching the tested patch to the file ifd-ccid.c to add support for
> the reader. The reader's USB IDs that I tested with are 0b97:7762 and
> 0b97:7772. Without this patch the ifd-ccid.c code will not work with these
> readers.
>
> The patch is based on th
On Sat, Jan 31, 2009 at 5:13 PM, Stefan X wrote:
> Hi, sorry for my late reply.
>
> Andreas, The "current" eGK contains fully crypto functionality such as
> decryption and signing. But the card is still in development and this
> version will not be identical to the distributed one. Nevertheless
>
s to be right but has no effect. The same
> messages appear as posted before.
>
> Alon Bar-Lev schrieb:
>> On Sat, Jan 31, 2009 at 5:13 PM, Stefan X wrote:
>>> Hi, sorry for my late reply.
>>>
>>> Andreas, The "current" eGK contains fully crypto
On Mon, Feb 2, 2009 at 7:41 PM, Jeffrey Hutzelman wrote:
> --On Monday, February 02, 2009 04:28:22 PM +0200 Alon Bar-Lev
> wrote:
>
>> The client library monitors /var/run/libscreader for changes
>
> That sounds really nonportable.
>
I have it working for Linux (
On Mon, Feb 2, 2009 at 8:02 PM, Jeffrey Hutzelman wrote:
> The way to do this is to have a single service which provides a rendesvous
> point for clients and readers, keeps track of what readers exist and of
> their state, informs clients of changes they are interested in, and mediates
> when more
On Monday 02 February 2009 21:58:17 Andreas Jellinghaus wrote:
> of limitations. also openct has a lot less to offer than pcsc-lite plus ccid,
> for example no working pinpad support.
This is driver issue not framework issue.
> I believe if all things pcsc-lite plus ccid can do would be added to
On Monday 02 February 2009 12:35:20 Aktiv Co. Aleksey Samsonov wrote:
> > also, do you know any resellers of the rutoken in eu?
>
> Unfortunately, Rutoken S is not exported from Russia.
Why?
Alon
___
opensc-devel mailing list
opensc-devel@lists.opensc-
Right.
Thanks!
On Mon, Feb 2, 2009 at 11:41 AM, Aktiv Co. Aleksey Samsonov
wrote:
>
> Is "ifdhandler" correct? (Not "openct.conf" or "openct.conf.new"?)
>
> Alon Bar-Lev:
>>
>> Should be.
>>
>> On 1/29/09, Aktiv Co. Aleksey S
On Monday 02 February 2009 14:09:12 Ludovic Rousseau wrote:
> Maybe it is time to let OpenCT die and use pcsc-lite only?
Ludovic, we discussed this off-list.
pcsc-lite has many disadvantages, I offered you my help and time in order to
work together to achieve single common framework for smartcar
Thanks for finding it!
I think best is to revert r942 and ask Kurt Jaeger for a different patch.
What do you think?
On 2/3/09, Chaskiel Grundman wrote:
>
>
> On Thu, 29 Jan 2009, Andrey Jivsov wrote:
>
> > I am attaching the tested patch to the file ifd-ccid.c to add support for
> the
> > rea
Thank you!
Applied.
On 2/3/09, Andrey Jivsov wrote:
> From:
> https://www.opensc-project.org/openct/browser/trunk/src/ifd/ifd-ccid.c
>
>if ((st->flags & FLAG_NO_SETPARAM) == 0 &&
> 1182((st->flags & FLAG_AUTO_ATRPARSE) == 0 |
> 1183proto != IFD_P
Hello Ludovic,
Thank you for replying.
On Tuesday 03 February 2009 12:42:40 Ludovic Rousseau wrote:
> I see _many_ advantages to your ideas. I even think of reusing some of them.
> What I don't want:
> - drop the IFDHandler API and drop support of existing drivers
> - engage in a multi-months de
I have pkcs11-dump at [1].
[1] http://alon.barlev.googlepages.com/pkcs11-utilities
On 2/3/09, Douglas E. Engert wrote:
> OpenSC is getting some bad press. (See below)
> The line in libp11 p11_key.c says:
> 111 * FIXME: We should check first whether the token supports
> 112 * on-boar
On Wednesday 04 February 2009 00:00:44 Martin Preuss wrote:
> As I see it the situation is this: There are applications which mandatory use
> the SCard interface provided by libpcsclite. There are other
> applications/libraries that can optionally use the SCard interface (as is the
> case with O
On Wednesday 04 February 2009 01:18:40 Martin Paljak wrote:
> If we talk about restructuring or "smoothing" the scene, we should
> really figure out some bits and pieces in the big picture and how they
> fit/should fit together to find the most rewarding locations to
> improve. Even if we r
On Wednesday 04 February 2009 15:00:11 Ludovic Rousseau wrote:
> Alon,
>
> What is the benefit of using:
>PKG_CHECK_EXISTS(
>[libpcsclite],
>[PKG_CHECK_MODULES([PCSC], [libpcsclite])]
> instead of just:
> PKG_CHECK_MODULES([PCSC
On Wednesday 04 February 2009 12:29:01 Martin Preuss wrote:
> Hi,
>
> On Dienstag, 3. Februar 2009, Alon Bar-Lev wrote:
> > On Wednesday 04 February 2009 00:00:44 Martin Preuss wrote:
> [...]
> > True. This is why I suggest separating the reader framework from
On Wednesday 04 February 2009 11:11:26 Ludovic Rousseau wrote:
> 2009/2/3 Alon Bar-Lev :
> > In time I believe commonly used drivers may be migrated into new framework,
> > to be more efficient, maintainable and share the common code base available
> > in the reader libr
On Thursday 05 February 2009 14:15:33 Andreas Jellinghaus wrote:
> Am Mittwoch 04 Februar 2009 19:55:33 schrieb Alon Bar-Lev:
> > I hope so... The dependency of libusb forces you to compromise. See how
> > clean the implementation of OpenCT is.
>
> take a look at the way usb
: We have daemonless standalone PC/SC implementation.
Until the next round...
Cheers,
Alon Bar-Lev
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
On Friday 06 February 2009 00:00:21 Ludovic Rousseau wrote:
> > pcsc-lite has some infrastructural limitations, that cannot be
> > easily fixed. it has no driver support environment, so
> > writing new drivers is difficult.
>
> Do you need a new driver for pcsc-lite? For which reader?
> Do you kno
On Friday 06 February 2009 00:57:18 Peter Stuge wrote:
> > The problem is that I do not have an unlimited amount of time. I
> > prefer to slowly improve pcsc-lite step-by-step rather than start a
> > new project from scratch.
>
> Please clarify this. I don't think you are saying that you will
> ne
On Friday 06 February 2009 01:08:29 Eddy Nigg (StartCom Ltd.) wrote:
> A clear voice of reason. If we can get a unified project out of this it
> would be terrific. I'll look into how we can support such a project, if
> and when I can see the attempts to align toward one well supported
> project.
On 2/6/09, Ludovic Rousseau wrote:
> I propose the attached patch. The idea is to sleep for 3 seconds if a
> CCID device is detected and pcsc-lite is also running.
> If the device is not claimed by a pcsc-lite driver then openct will
> use it as before.
>
> I could not test the patch. I can't
On 2/6/09, Andreas Jellinghaus wrote:
> For the record, I completely agree with ludovics posting.
>
> Alon wants other people to fix the problem he found, but not
> even help in reproducing or debugging it. Alon wants to commitment
> to a new design he came up with, one that leaves many, many o
On 2/6/09, Andreas Jellinghaus wrote:
> Am Freitag 06 Februar 2009 00:25:27 schrieb Alon Bar-Lev:
>
> > The above is what I requested. I write the new framework using a goal
> > we agree upon, and if I achieve those goals, we mark pcsc-lite and
> > OpenCT as obsolet
On Friday 06 February 2009 10:33:53 Ludovic Rousseau wrote:
> 2009/2/6 Alon Bar-Lev :
> > I did not require much of Ludovic time.
> > After I implement the framework and the difficult PC/SC verbs:
> > SCardBeginTransaction
> > SCardEndTransaction
> > SCa
On Friday 06 February 2009 15:06:25 Andreas Jellinghaus wrote:
> Am Freitag 06 Februar 2009 13:36:58 schrieb Ludovic Rousseau:
> > > also 3 seconds seems quite long to me.
> >
> > Only if you also have pcscd running.
> >
> > The patch will impact only people with the following configuration:
> > -
On Tuesday 10 February 2009 20:38:30 Douglas E. Engert wrote:
> I have some more basic questions of the people in this discussion.
>
> Have any of you met face to face?
Did not met anyone.
>
> What are your motives in getting involved in OpenSC?
>
I began with this mission:
>From my public p
On Monday 09 February 2009 18:05:20 Andreas Jellinghaus wrote:
> picking up only a few lines from your long post:
>
> > The build system of OpenSC was a mess.
> I didn't think of it that badly. but it was me who wrote it, and I still
> think it was better than what we had before.
As I don't know
Hello,
On Saturday 07 February 2009 14:23:30 Ludovic Rousseau wrote:
> 2009/2/6 Alon Bar-Lev :
> > 3. CCID driver
> >
> > The CCID driver will be migrated to the new framework, dropping the libusb
> > usage
> > and use USB directly, this way it would be more e
Should not happen.
Please provide debug log.
Alon
On 2/12/09, Roman Himmes wrote:
> Hello,
>
> the applciation I write has to store data on different parts of a
> crypto token protected by different pins.
> I discovered that I have to reload the opensc-pkcs11.dll when trying
> to access th
88 Error in C_CreateObject (error code: 257)
>
>
> So I cannot even access the Data on Slot0 again.
>
> Greetings,
>
> Roman
>
>
>
>
>
>
> Am 12.02.2009 um 14:29 schrieb Alon Bar-Lev:
>
>
> > Should not happen.
> > Please provide debug lo
On 2/12/09, Ludovic Rousseau wrote:
> > I thought of using the stable API to implement some other application APIs,
> > and maybe convince developers who accessed the reader directly to use
> > the new infrastructure (GnuPG, coolkey etc).
>
>
> It may be hard to convince the GnuPG project. GnuP
On 2/14/09, Martin Preuss wrote:
> Difficult to work with us? (asking as the maintainer of the cyberjack driver
> for Linux)??
I found this [1], while I tried to make source tarball be more
suitable as standalone installable module (without rpm or deb).
Long forgotten.
Anyway... While you are
On Sat, Feb 14, 2009 at 9:45 PM, Martin Preuss wrote:
>> Can you please write the reasons why did you chose to access the
>> reader directly and not use PC/SC within utilities?
> [...]
>
> The base of the driver was created when PC/SC wasn't that popular under Linux,
> so the developers at that ti
On 2/18/09, Douglas E. Engert wrote:
> My question is should the code in slot_get_token try and detect if
> the card has been changed, by calling card_detect every time,
> or at least try the sc_lock/sc_unlock to test if the card is still
> there? It would appear that at a C_OpenSession this
On 2/20/09, Douglas E. Engert wrote:
> I was not using the PKG, but setting OPENSSL_CFLAGS and OPENSSL_LIBS.
> The problem is AC_CHECK_LIB will check the crypto library
> for the function: RSA_version.
>
> But RSA_version is not a function! It is a pointer to a char:
> const char *RSA_version
On 2/20/09, Douglas E. Engert wrote:
> The build page points at the opensc-i686-mingw-[001|002]* files
> from July and August. I started from the
> http://www.opensc-project.org/files/opensc/opensc-0.11.7-rc1.tar.gz
> There is no build script there.
> I do see one in the SVN.
The build script
On Wed, Feb 25, 2009 at 12:19 PM, Marc Rios Valles wrote:
>> Do you also have the problem using the version in subversion?
>>
> Not, in subversion works ok but is not the same method isn't it?
This was fixed in trunk.
Thanks,
Alon.
___
opensc-devel mai
Thanks!
I fixed the pkcs11-helper, that was easy.
Andreas, I just discovered the /doc something...
I guess this is automatic generation of packages?
Alon.
On Fri, Mar 6, 2009 at 10:19 AM, Dominik Fischer wrote:
> Hello,
>
> the following links to APIs are broken:
>
> http://www.opensc-project.o
WOW! Thanks for finding this!
Ludovic, can you please confirm this? pcsc-lite diffrence from Windows.
It is used by CM_IOCTL_GET_FEATURE_REQUEST,
So:
#define CM_IOCTL_GET_FEATURE_REQUEST SCARD_CTL_CODE(3400)
Should be actually be:
#define CM_IOCTL_GET_FEATURE_REQUEST SCARD_CTL_CODE(850)
Thanks!
2009/3/6 Martin Paljak :
> SCardControl talks to reader drivers, not pcsc-lite or pc/sc subsystem in
> that matter.
>
> 3400 was the "original reference number" in teletrust (which later became
> PC/SC v2 part 10 which deals with pinpads).
> Historic note: http://osdir.com/ml/lib.muscle/2005-03/msg
On Sat, Mar 7, 2009 at 6:51 PM, Ludovic Rousseau
wrote:
> Providing a internal-winscard.h is not a good idea. You should use the
> header file provided by the library you want to use.
> I already warned of the (potential) problem in [1].
For all of those who keep mentioning that...
Please come f
Thank you, fixed in r3662.
And build-004 was released with this fix.
Alon.
On Wed, Feb 25, 2009 at 11:27 AM, Fleblanc wrote:
> Opensc release 0.11.6
>
> Platform Windows XP
>
> Reader XIRING CCID with pinpad
>
>
> Two things:
>
> First when I connect this reader and other PCSC readers when I us
On Sat, Mar 7, 2009 at 11:44 PM, Ludovic Rousseau
wrote:
> This could be an option with a major release of pcsc-lite (maybe the
> one you are working on)
Well... I didn't got any response from the last summery message...
So I thought I begin with providing PC/SC client side for OpenCT,
as it wil
24:54:32:FF:FF:FF:FF:FF
>>
>> apdu to verify will be:
>>
>> 00 20 00 00 08 24 54 32 FF FF FF FF FF
>>
>> so pin start at lc + 8 bits...
>>
>> This, the code should be:
>>
>> tmp |= 0x08 << 3;
>>
>> Of course I've a rea
This is not required, as one can get this from private key attributes
or from the certificate.
It just waste card storage...
I read the message in reference, and I think that there should be a
different solution for this
without storing the public key.
Alon.
On Thu, Mar 12, 2009 at 10:33 AM, wr
y public key each time you
> want to verify anything?
>
> If you still do not want to create a public key token object, then you
> have to rewrite some of the functions in pkcs11-tool that requires the
> public key.
>
> 12 mar 2009 kl. 19.49 skrev "Alon Bar-Lev" :
>
&
On Fri, Mar 13, 2009 at 10:00 AM, Rickard Bondesson
wrote:
> Well ok, you can extract CKA_MODULUS and CKA_PUBLIC_EXPONENT from the private
> key. Which is needed for the public key.
>
> But pkcs11-tool does not do that. It segfaults during the test function:
>
> Signatures (currently only RSA si
301 - 400 of 644 matches
Mail list logo
