Andreas Jellinghaus wrote:
> This patch creates a new libopensc containing those three libraries.
> The export list contains all symbols exported by those three.
>
> common/libcompat.la is also linked into libopensc, but not exported.
> The tools thus link common/libcompat.la themself.
>
> Is this
On Feb 1, 2010, at 10:27 , Viktor TARASOV wrote:
> Andreas Jellinghaus wrote:
>> This patch creates a new libopensc containing those three libraries.
>> The export list contains all symbols exported by those three.
>>
>> common/libcompat.la is also linked into libopensc, but not exported.
>> The t
Martin Paljak wrote:
> On Feb 1, 2010, at 10:27 , Viktor TARASOV wrote:
>
>> Andreas Jellinghaus wrote:
>>
>>> This patch creates a new libopensc containing those three libraries.
>>> The export list contains all symbols exported by those three.
>>>
>>> common/libcompat.la is also linked in
Hi,
I did not understand:
-lib_LTLIBRARIES = libopensc.la
+noinst_LTLIBRARIES = libopensc.la
why not installing the libopensc?
if you don't a copy of the library will exist in every tool and other library.
Alon.
On Mon, Feb 1, 2010 at 9:14 AM, Andreas Jellinghaus
wrote:
>
> This patch creates
Thank you very much for you answer.
I've downloaded the last 32 bit compiled version of opensc project
http://www.opensc-project.org/files/build/opensc-i686-w64-mingw32-008-base.tar.bz2
With these tools, pkcs15-init seems to work properly. However,
pkcs11-tool shows the error below:
/
/
/err
Am Montag 01 Februar 2010 11:16:42 schrieb Alon Bar-Lev:
> Hi,
>
> I did not understand:
> -lib_LTLIBRARIES = libopensc.la
> +noinst_LTLIBRARIES = libopensc.la
>
> why not installing the libopensc?
> if you don't a copy of the library will exist in every tool and other
> library.
there is a new
Am Montag 01 Februar 2010 11:53:52 schrieb evalues:
> With these tools, pkcs15-init seems to work properly. However,
> pkcs11-tool shows the error below:
try pkcs11-tool --module path\to\opensc-pkcs11.dll and see
if that helps.
Regards, Andreas
___
open
slightly updated version with build fixes
(top_srcdir vs. top_builddir and compile libcompat
into opensc-pkcs11.so too).
Andreas
diff -udrNPp --exclude=.svn opensc.orig/src/libopensc/Makefile.am opensc/src/libopensc/Makefile.am
--- opensc.orig/src/libopensc/Makefile.am 2010-02-01 08:03:26.
Won't it be simpler to leave libopensc as-is and encapsulate the pkcs15init?
Having two libopensc is quite confusing...
Anyway, there are problems with the patch, I don't have time right now
to go over this, please don't commit yet.
Examples:
1. src/pkcs15init/Makefile.am, still need to rename lib
On Feb 1, 2010, at 14:04 , Alon Bar-Lev wrote:
> Having two libopensc is quite confusing...
Same here...
--
Martin Paljak
http://martin.paljak.pri.ee
+3725156495
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-pro
Am Montag 01 Februar 2010 13:15:00 schrieb Martin Paljak:
> On Feb 1, 2010, at 14:04 , Alon Bar-Lev wrote:
> > Having two libopensc is quite confusing...
>
> Same here...
don't you like the change in content? i.e. new libopensc.so
(installed) = old libopensc.so plus libscconf.so plus libpkcs15ini
Hi,
actually this card is the only one that partly uses the Old pkcs15init API.
I would like to migrate it to the New API.
Aventure Ltd. webshop do not propose this card .
Do you know, where can I get it, please?
Kind wishes,
Viktor.
--
Viktor Tarasov
_
Am Montag 01 Februar 2010 13:04:57 schrieb Alon Bar-Lev:
> Won't it be simpler to leave libopensc as-is and encapsulate the
> pkcs15init?
hmm, I thought you need to compile libopensc first and then
compile pkcs15init. if you think the other way would work too,
yes, the final "libopensc.so" can be
are you trying to get new blank card initialized with opensc to work,
or are you trying to get cards with that vendors software to work
with opensc?
if that vendor did not implement PKCS#15 on the cards, the resulting
card might not be compatible with opensc.
opensc is supposed to be compatible w
Am Montag 01 Februar 2010 14:07:28 schrieb Viktor TARASOV:
> Hi,
>
> actually this card is the only one that partly uses the Old pkcs15init API.
>
> I would like to migrate it to the New API.
>
> Aventure Ltd. webshop do not propose this card .
>
> Do you know, where can I get it, please?
try
Hello.
On Feb 1, 2010, at 15:07 , Viktor TARASOV wrote:
> actually this card is the only one that partly uses the Old pkcs15init API.
This card was added just recently (September 2009) so there should not be many
(if any) public users and the developer should be reachable (added to Cc just
in ca
Am Montag 01 Februar 2010 13:15:00 schrieb Martin Paljak:
> On Feb 1, 2010, at 14:04 , Alon Bar-Lev wrote:
> > Having two libopensc is quite confusing...
>
> Same here...
>
ok, new version. pkcs15init is build before libopensc/ directory,
and the shared library is now created in libopensc/ as it
Hi,
I propose to change slightly the prototypes of the
sc_pkcs15init_operations procedures,
(excluding maybe 'erase_card', 'init_card', ),
and to pass the 'sc_pkcs15_card' argument instead of 'sc_card' .
For ex. to change
int (*create_key)(sc_profile_t *, sc_card_t *, sc_pkcs15_object_t *)
fo
OK.
This compiles now.
But why did you touch:
-mylib_DATA=.libs/@win_libpre...@opensc-@opensc_lt_old...@.dll.def
-.libs/@win_libpre...@opensc-@opensc_lt_old...@.dll.def:libopensc.la
+# not sure what to put here as mylib_DATA ?
+mylib_DATA=.libs/@win_libpre...@libopensc-@opensc_lt_old...@.d
Am Montag 01 Februar 2010 15:10:05 schrieb Viktor TARASOV:
> Sure, one can tell that card specific part can access the sc_pkcs15_card
> through the profile->p15_spec,
> but, imho, direct manner looks better.
fine with me.
btw: if you need to touch pkcs11/ for that, maybe you know the
code best: I
Am Montag 01 Februar 2010 15:28:30 schrieb Alon Bar-Lev:
> OK.
> This compiles now.
>
> But why did you touch:
oops, leftover. reverted.
thanks, I commited the changes so far.
Regards, Andreas
___
opensc-devel mailing list
opensc-devel@lists.opensc-pr
On Feb 1, 2010, at 17:07 , Andreas Jellinghaus wrote:
> Am Montag 01 Februar 2010 15:10:05 schrieb Viktor TARASOV:
>> Sure, one can tell that card specific part can access the sc_pkcs15_card
>> through the profile->p15_spec,
>> but, imho, direct manner looks better.
>
> fine with me.
>
> btw: if
Am Montag 01 Februar 2010 09:27:11 schrieb Viktor TARASOV:
> Andreas Jellinghaus wrote:
> > This patch creates a new libopensc containing those three libraries.
> > The export list contains all symbols exported by those three.
> >
> > common/libcompat.la is also linked into libopensc, but not expor
Am Montag 01 Februar 2010 16:28:46 schrieb Andreas Jellinghaus:
> there is this central
> versioninfo.rc file in win32. but src/libopensc/ has a versioninfo.rc
> code in Makefile.am too. strange. and some apps are linked with
> versioninfo.rc, but not all (test, scconf, common, ... might be
> missi
I distribute the .rc file in the tarball in order for the MSC build
system to be able to use it.
Had we supported only one build system (autoconf) we could have
avoided this and produce much cleaner solution.
I can remove all the generated files from the tarball if they are not
used anywhere.
On M
On Feb 1, 2010, at 17:39 , Alon Bar-Lev wrote:
> I distribute the .rc file in the tarball in order for the MSC build
> system to be able to use it.
> Had we supported only one build system (autoconf) we could have
> avoided this and produce much cleaner solution.
> I can remove all the generated fi
Am Montag 01 Februar 2010 16:26:09 schrieb Martin Paljak:
> In real life the two frameworks are deeply interconnected and
> interdependent for now.
>
> It looks like a logical move to me.
so is this something that needs to be kept that way,
to support both read-only/emulated cards and cards wit
Am Montag 01 Februar 2010 16:39:42 schrieb Alon Bar-Lev:
> I distribute the .rc file in the tarball in order for the MSC build
> system to be able to use it.
> Had we supported only one build system (autoconf) we could have
> avoided this and produce much cleaner solution.
> I can remove all the ge
One more thing Viktor:
I saw Makefile.mak and Make.rules etc. container /machine:ix86.
Is that the microsoft code for 32bit dll?
should we continue to hard code that, or allow compiling 64bit too?
no idea what is best. I guess firefox and most apps are still 32bit,
so creating a 32bit pkcs#11 mod
Andreas Jellinghaus wrote:
> Am Montag 01 Februar 2010 15:10:05 schrieb Viktor TARASOV:
>
>> Sure, one can tell that card specific part can access the sc_pkcs15_card
>> through the profile->p15_spec,
>> but, imho, direct manner looks better.
>>
>
> fine with me.
>
> btw: if you need to touc
Martin Paljak wrote:
> On Feb 1, 2010, at 17:07 , Andreas Jellinghaus wrote:
>
>> Am Montag 01 Februar 2010 15:10:05 schrieb Viktor TARASOV:
>>
>>> Sure, one can tell that card specific part can access the sc_pkcs15_card
>>> through the profile->p15_spec,
>>> but, imho, direct manner looks
On Feb 1, 2010, at 17:51 , Andreas Jellinghaus wrote:
> One more thing Viktor:
>
> I saw Makefile.mak and Make.rules etc. container /machine:ix86.
> Is that the microsoft code for 32bit dll?
> should we continue to hard code that, or allow compiling 64bit too?
>
> no idea what is best. I guess fi
Am Montag 01 Februar 2010 17:51:28 schrieb Viktor TARASOV:
> As for alternative to pkcs#15 -- I don't feel what for.
>
> (One can say that the alternative to pkcs#15 is already realized by the
> OpenSC itself -- with its emulators for the non-pkcs15 cards . )
>
> Maybe someone else can give the u
33 matches
Mail list logo
