Re: [opensc-devel] cross build system ( does opensc (svn version) work for you?)
2009/1/25 Alon Bar-Lev : > 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? The binaries are installed in build/trunk/image/, aren't they? If so it does not work. trunk/image/opensc/bin$ ./opensc-tool dyld: Library not loaded: //lib/libopensc.2.dylib Referenced from: /Users/lroussea/Documents/sc/OpenSC/build/trunk/image/opensc/bin/./opensc-tool Reason: image not found Trace/BPT trap trunk/image/opensc/bin$ otool -L ./opensc-tool ./opensc-tool: //lib/libopensc.2.dylib (compatibility version 3.0.0, current version 3.0.0) //lib/libcrypto.0.9.9.dylib (compatibility version 0.9.9, current version 0.9.9) //lib/libopenct.1.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) //lib/libltdl.3.dylib (compatibility version 5.0.0, current version 5.6.0) //lib/libscconf.2.dylib (compatibility version 3.0.0, current version 3.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) The binaries are using/referencing the libraries from //lib instead of [.]/trunk/image/opensc/lib/ I do not want to invest more time in this build script since I do not use OpenSC on Mac OS X. Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] cross build system ( does opensc (svn version) work for you?)
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/build/trunk/image/opensc/bin/./opensc-tool > Reason: image not found > Trace/BPT trap Jean-Pierre, if you like you can use this, I am sure it almost ready. The above issue is caused by the root location. If you set OPENSC_TARGET_ROOT to something sensible then it should work. Executing directly from the image will probably require OPENSC_TARGET_ROOT=/Users/lroussea/Documents/sc/OpenSC/build/trunk/image/opensc Thanks! Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] does opensc (svn version) work for you?
Alon Bar-Lev a écrit : > 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 dump of the libp11.so symbols. > > I use: > readelf --syms /usr/lib/libp11.so > > Alon. > > Hi, I found maybe the problem. In the linker step, the installed version /Library/OpenSC/lib/libp11.dylib is used. This one didn't contain a reference to _PKCS11_CTX_init_args if I check with otool -Rv. The freshly compiled version /Users/jps/Documents/opensc/compiled-libp11-i386/Library/OpenSC/lib/libp11.dylib contains this reference. I will try to fix this by hand and to finish the complete compilation of a test SCA release. Jean-Pierre ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] cross build system ( does opensc (svn version) work for you?)
2009/1/26 Alon Bar-Lev : > Jean-Pierre, if you like you can use this, I am sure it almost ready. > The above issue is caused by the root location. > > If you set OPENSC_TARGET_ROOT to something sensible then it should work. > Executing directly from the image will probably require > OPENSC_TARGET_ROOT=/Users/lroussea/Documents/sc/OpenSC/build/trunk/image/opensc What are your supposed to do with the image? How are you supposed to _install_ the software? bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] cross build system ( does opensc (svn version) work for you?)
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 into the initramfs root. If you want to copy it to /usr/local/ using a package manager or whatever you can do this as well if you set the right value of OPENSC_TARGET_ROOT. Basically after you set the OPENSC_TARGET_ROOT you need to deliver the software to destination machie and place it in OPENSC_TARGET_ROOT. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] cross build system ( does opensc (svn version) work for you?)
On 26.01.2009, at 14:49, Alon Bar-Lev wrote: > If you want to copy it to /usr/local/ using a package manager or > whatever you can do this as well if you set the right value of > OPENSC_TARGET_ROOT. > Basically after you set the OPENSC_TARGET_ROOT you need to deliver the > software to destination machie and place it in OPENSC_TARGET_ROOT. Compared to SCA installer, this means /Library/OpenSC -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] [OpenCT] #31: T1 protocol abort handling
2008/12/19 Ludovic Rousseau :
> I will try to merge my T=1 code in OpenCT. But not before a few weeks.
> I remembered some objections when I proposed to do this a few years
> ago. Maybe the situation has changed.
I patched the OpenSC version of src/ifd/proto-t1.c (patch attached)
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 fields are only present in the
t1_state_t structure
- t1_negotiate_ifsd() is declared in src/ifd/internal.h and the only
external source using it is src/ifd/ifd-eutron.c. This function is
never used elsewhere. This function could be used by the CCID driver
if the reader does not negotiate the IFSD itself for example
- I changed my version of proto-t1.c in my CCID handler to make
comparison more easy
I can integrate some patches from my CCID driver. But integrating all
the error cases management will be very hard without major changes in
OpenCT.
What should I do?
Bye
--
Dr. Ludovic Rousseau
Index: proto-t1.c
===
--- proto-t1.c (révision 1127)
+++ proto-t1.c (copie de travail)
@@ -8,6 +8,8 @@
*/
#include "internal.h"
+#include "openct/buffer.h"
+
#include
#include
#include
@@ -15,6 +17,7 @@
typedef struct {
ifd_protocol_t base;
+ int lun;
int state;
int block_oriented;
@@ -29,6 +32,9 @@ typedef struct {
unsigned int (*checksum) (const unsigned char *,
size_t, unsigned char *);
+
+ char more; /* more data bit */
+ unsigned char previous_block[4];/* to store the last R-block */
} t1_state_t;
/* T=1 protocol constants */
@@ -56,24 +62,40 @@ typedef struct {
#define T1_S_WTX 0x03
#define T1_BUFFER_SIZE (3 + 254 + 2)
+#define swap_nibbles(x) ( (x >> 4) | ((x & 0xF) << 4) )
+
+#ifndef TRUE
+#define TRUE 1
+#define FALSE 0
+#endif
#define NAD 0
#define PCB 1
#define LEN 2
#define DATA 3
+#define DEBUG_INFO2(a, b) ifd_debug(1, a, b)
+#define DEBUG_CRITICAL(a) ifd_debug(1, a)
+#define DEBUG_CRITICAL2(a, b) ifd_debug(1, a, b)
+#define DEBUG_COMM(a) ifd_debug(3, a)
+#define DEBUG_COMM2(a, b) ifd_debug(3, a, b)
+#define DEBUG_COMM4(a, b, c, d) ifd_debug(3, a, b, c, d)
+#define DEBUG_XXD(a, b, c) do{}while(0)
+
/* internal state, do not mess with it. */
/* should be != DEAD after reset/init */
enum {
SENDING, RECEIVING, RESYNCH, DEAD
};
+static int t1_set_param(t1_state_t * t1, int type, long value);
static void t1_set_checksum(t1_state_t *, int);
static unsigned int t1_block_type(unsigned char);
static unsigned int t1_seq(unsigned char);
-static unsigned int t1_build(t1_state_t *, unsigned char *,
-unsigned char, unsigned char,
-ct_buf_t *, size_t *);
+unsigned int t1_build(t1_state_t * t1, unsigned char *block,
+ unsigned char dad, unsigned char pcb,
+ ct_buf_t *bp, size_t *lenp);
+static unsigned int t1_rebuild(t1_state_t *t1, unsigned char *block);
static unsigned int t1_compute_checksum(t1_state_t *, unsigned char *, size_t);
static int t1_verify_checksum(t1_state_t *, unsigned char *, size_t);
static int t1_xcv(t1_state_t *, unsigned char *, size_t, size_t);
@@ -111,24 +133,22 @@ static void t1_set_checksum(t1_state_t *
/*
* Attach t1 protocol
*/
-static int t1_init(ifd_protocol_t * prot)
+static int t1_init(t1_state_t * t1, int lun)
{
- t1_state_t *t1 = (t1_state_t *) prot;
-
t1_set_defaults(t1);
- t1_set_checksum(t1, IFD_PROTOCOL_T1_CHECKSUM_LRC);
+ t1_set_param(t1, IFD_PROTOCOL_T1_CHECKSUM_LRC, 0);
+ t1_set_param(t1, IFD_PROTOCOL_T1_STATE, SENDING);
+ t1_set_param(t1, IFD_PROTOCOL_T1_MORE, FALSE);
+
+ t1->lun = lun;
- /* If the device is attached through USB etc, assume the
-* device will do the framing for us */
- if (prot->reader->device->type != IFD_DEVICE_TYPE_SERIAL)
- t1->block_oriented = 1;
return 0;
}
/*
* Detach t1 protocol
*/
-static void t1_release(ifd_protocol_t * prot)
+static void t1_release(t1_state_t * t1)
{
/* NOP */
}
@@ -136,17 +156,12 @@ static void t1_release(ifd_protocol_t *
/*
* Get/set parmaters for T1 protocol
*/
-static int t1_set_param(ifd_protocol_t * prot, int type, long value)
+static int t1_set_param(t1_state_t * t1, int type, long value)
{
- t1_state_t *t1 = (t1_state_t *) prot;
-
switch (type) {
case IFD_PROTOCOL_RECV_TIMEOUT:
t1->timeout = value;
break;
- case IFD_PROTOCOL_BLOCK_ORIENTED:
- t1->block_oriented = value;
- break;
case IFD_PROTOCOL_T1_CHECKSUM_LRC:
case IFD_PROTOCOL_T1_CHECKSUM_CRC:
t1_set_checksum(t1, type);
@@ -157,8 +172,14 @@ static int t1_set_param(ifd_protocol_t *
case IFD_PRO
Re: [opensc-devel] [opensc-commits] [OpenCT] #31: T1 protocol abort handling
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 fields are only present in the > t1_state_t structure > - t1_negotiate_ifsd() is declared in src/ifd/internal.h and the only > external source using it is src/ifd/ifd-eutron.c. This function is > never used elsewhere. This function could be used by the CCID driver > if the reader does not negotiate the IFSD itself for example > - I changed my version of proto-t1.c in my CCID handler to make > comparison more easy > > I can integrate some patches from my CCID driver. But integrating all > the error cases management will be very hard without major changes in > OpenCT. > > What should I do? What do you mean "patches from CCID driver"? Other than T1? I only thought to make the T1 common, so I can compare the CCID implementation. Looking ahead, do you think it will be easier to integrate OpenCT CCID into new framework or your CCID? I think that OpenCT is closer... as it does not use libusb or daemon. Thank you! Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] [OpenCT] #31: T1 protocol abort handling
2009/1/26 Alon Bar-Lev : > 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 fields are only present in the >> t1_state_t structure >> - t1_negotiate_ifsd() is declared in src/ifd/internal.h and the only >> external source using it is src/ifd/ifd-eutron.c. This function is >> never used elsewhere. This function could be used by the CCID driver >> if the reader does not negotiate the IFSD itself for example >> - I changed my version of proto-t1.c in my CCID handler to make >> comparison more easy >> >> I can integrate some patches from my CCID driver. But integrating all >> the error cases management will be very hard without major changes in >> OpenCT. >> >> What should I do? > > What do you mean "patches from CCID driver"? Other than T1? 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. > I only > thought to make the T1 common, so I can compare the CCID > implementation. > Looking ahead, do you think it will be easier to integrate OpenCT CCID > into new framework or your CCID? I think that OpenCT is closer... as > it does not use libusb or daemon. The OpenCT CCID is "very" limited. For example I just discovered it does not negotiate the IFSD (maximum block size supported by the reader) so the card will not send blocks bigger than 32 bytes (default value). I also think it does not support multi-slots readers And it does not support Secure Pin Entry I have never used OpenCT so I can't defend it or its CCID driver. -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] [OpenCT] #31: T1 protocol abort handling
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 the IFSD (maximum > block size supported by the reader) so the card will not send blocks > bigger than 32 bytes (default value). > I also think it does not support multi-slots readers > And it does not support Secure Pin Entry > > I have never used OpenCT so I can't defend it or its CCID driver. OK... Although your CCID is not using clean context, and has some global variables... Also much more legacy code. No need to decide now. Thanks, Alon ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
