Hello,
> Xiaoshuo Wu wrote:
>> On Sun, 17 Jan 2010 20:36:53 +0800, Xiaoshuo Wu
>> wrote:
>>
>>> I'd like to hear your plan for these changes so as to help me fix this.
>> I recovered cache_pin() in rev 3783, renamed it add_pins_to_keycache()
>> and had some adjustment. When login/change PIN/init
Hello,
Committed at trunk revision 3891.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Martin Paljak:
> I don't think that obvious fixes for spec conformance need any vetting
> period. +1 anyway.
Thanks. Committed at trunk revision 3886.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mail
Aktiv Co. Aleksey Samsonov:
> or
> 1. no for the present and to try further (that'll do
> CKR_TEMPLATE_INCOMPLETE, CKR_OK and etc)
Incidentally:
CK_MECHANISM gostMech = { CKM_GOSTR3410_KEY_PAIR_GEN, NULL, 0 };
...
C_GenerateKeyPair(hSession, &gostMech, NULL_PTR, 0, NULL
Hi Martin,
Martin Paljak:
> On 08.12.2009, at 14:09, Aktiv Co. Aleksey Samsonov wrote:
>
>>> Any idea?
>> C_CreateObject, C_FindObjectsInit, C_GenerateKeyPair, C_UnwrapKey :
>>
>> 1) if (pTemplate == NULL_PTR && ulCount > 0) { rv = CKR_ARGUMENTS_BAD;
> Any idea?
C_CreateObject, C_FindObjectsInit, C_GenerateKeyPair, C_UnwrapKey :
1) if (pTemplate == NULL_PTR && ulCount > 0) { rv = CKR_ARGUMENTS_BAD;
vs
2) if (pTemplate == NULL_PTR || ulCount == 0) { rv = CKR_ARGUMENTS_BAD;
?
___
opensc-devel mail
Hello,
I propose a patch for PKCS#11
Fix: return CKR_SESSION_READ_ONLY from C_InitPIN, C_SetPIN,
C_CreateObject, C_CopyObject, C_DestroyObject, C_SetAttributeValue,
C_GenerateKey, C_GenerateKeyPair, C_UnwrapKey, C_DeriveKey if session is
read-only.
PKCS#11:
"C_InitPIN can only be called in t
Hello,
I propose a patch for PKCS#11
Fix: any of these calls
C_CreateObject(hSession, NULL_PTR, 1, NULL_PTR);
C_GetAttributeValue(hSession, hObject, NULL_PTR, 1);
C_SetAttributeValue(hSession, hObject, NULL_PTR, 1);
C_FindObjectsInit(hSession, NULL_PTR, 1);
C_FindObjects(hSession, NULL_PTR, 0, NU
Viktor TARASOV:
>> - in CKU_SO_PIN context -- set PIN after SOPIN authentication;
>>
> Sorry, it's not good idea -- there should be possibility to change SOPIN.
Incidentally, this isn't work for current trunk. (change SOPIN by
C_SetPin) (see slot_data_auth/slot_data_pin_info and
http://www.open
Viktor TARASOV:
> Another possible, 'alternative to alternative' scheme is to use C_SetPin()
> in the specific context (after C_Login(CKU_SPECIFIC_CONTEXT)).
>
> So, in CKU_USER_PIN context C_SetPin() is used to change user PIN,
> in CKU_CONTEXT_SPECIFIC it's used to unblock user PIN.
>
> Afais,
Pierre Ossman:
> I think we might have a language barrier here as I'm not quite
> following what you're trying to say.
Sorry for inconvenience caused.
> The basic problem is that none of my PKCS#15 cards have an object for
> the PUK (and from what I can tell the PKCS#15 standard doesn't require
>
Pierre Ossman:
> On Wed, 2 Dec 2009 12:48:56 +0300
> "Aktiv Co. Aleksey Samsonov" wrote:
>> Pierre Ossman:
>>> I've had another look at this and implemented a somewhat ugly hack to
>>> provide this functionality. Basically C_Login will return success f
Pierre Ossman:
> On Wed, 2 Dec 2009 12:48:56 +0300
> "Aktiv Co. Aleksey Samsonov" wrote:
>> Pierre Ossman:
>>> Comment away!
>> Please see:
>> http://www.opensc-project.org/pipermail/opensc-devel/2009-November/012894.html
>> http://www.opensc
Pierre Ossman:
> I've had another look at this and implemented a somewhat ugly hack to
> provide this functionality. Basically C_Login will return success for
> CKU_SO if it can't find an auth object and then rely on the PIN cache
> in C_InitPIN.
>
> Comment away!
Please see:
http://www.opensc-pr
François Leblanc:
> Hi there,
Hi,
> Does someone do commands like :
>
> pkcs11-tool -l -O
>
> It fails for me:
>
> error: PKCS11 function C_OpenSession failed: rv = CKR_TOKEN_NOT_PRESENT (0xe0)
>
> but if I do :
>
> pkcs11-tool -T
> Available slots:
> Slot 4 CEVGroup Software Reade
Hello,
After changeset 3784
http://www.opensc-project.org/opensc/changeset/3784/branches
Give special attention to:
-static void cache_pin(void *, int, const sc_path_t *, const void *,
size_t);
and
http://www.opensc-project.org/opensc/browser/branches/martin/0.12/src/pkcs11/framework-pkcs15.c
Viktor TARASOV:
> Aktiv Co. Aleksey Samsonov wrote:
>> Viktor TARASOV:
>
>>> It's commited ...
>> Thanks, but some remarks:
>>
>> Potencial memory leaks (see /* */):
>
> Thanks for your code revision. I'll be more attentive.
>
> Consi
Viktor TARASOV:
> Aktiv Co. Aleksey Samsonov wrote:
>> Viktor TARASOV:
>>> Hi,
>> Hi
Hi,
>>> Nevertheless, IMHO, it would be nice, for the cryptographic objects (and
>>> maybe for the others)
>>> to have the possibility of some unique ID calcula
Viktor TARASOV:
> Hi,
Hi
> Nevertheless, IMHO, it would be nice, for the cryptographic objects (and
> maybe for the others)
> to have the possibility of some unique ID calculated from the object
> itself, as it was discussed in thread:
> 'CKA_ID and pkcs15 ID' 05.09.2005 13:34 .
>
> The idea is
Hello,
Aventra development:
> Does the other drivers work when initializing a card, and is the ACL set
> correctly?
The ACL is set correctly for Rutoken.
Example (Rutoken ECP): $ pkcs15-init -E -C --so-pin "87654321" --so-puk
"" 2>&1 > 1.txt
1.txt attached
See:
card.c:362:sc_create_file: call
Aktiv Co. Aleksey Samsonov:
> Hello,
>
> Kalev Lember:
>> On 10/23/2009 04:39 PM, Andreas Jellinghaus wrote:
>>> Please give it a final test.
>>>
>>> http://www.opensc-project.org/files/opensc/testing/opensc-0.11.11-rc1.tar.gz
>>>
>&
Hello,
Kalev Lember:
> On 10/23/2009 04:39 PM, Andreas Jellinghaus wrote:
>> Please give it a final test.
>>
>> http://www.opensc-project.org/files/opensc/testing/opensc-0.11.11-rc1.tar.gz
>
> Doesn't seem to compile with openssl-1.0 beta3 (distributed with Fedora
> 12, for example):
>
> /bin/sh
Hello,
Andreas Jellinghaus:
> here is a preview to 0.11.11, it contains a fix
> for compiling with openssl 0.9.7. please give it a try.
I'm going to support GOST in tools, also I have some time to cleanup and
fix warnings. Do we need a new branch?
Thanks
_
Hi,
Andreas Jellinghaus:
> Hi,
>
> I made a preview in case we forgot something important.
> if you find some time, please test and report back. thanks!
>
> http://www.opensc-project.org/files/opensc/testing/opensc-0.11.10-pre1.tar.gz
My tests are working.
Thanks
__
Hello,
Aktiv Co. Aleksey Samsonov:
> I think, we need to rollback:
>
> Index: src/pkcs15init/keycache.c
> ===
> --- src/pkcs15init/keycache.c (revision 3765)
> +++ src/pkcs15init/keycache.c (working copy)
&g
Hello,
Andreas Jellinghaus:
> Am Dienstag 06 Oktober 2009 16:06:52 schrieb Aktiv Co. Aleksey Samsonov:
>> Aktiv Co. Aleksey Samsonov:
>>> Hello,
>>> Rutoken initialization failed after
>>> http://www.opensc-project.org/opensc/changeset/3765#file8
>>>
Hello,
Thanks for the answer.
I think that this code is become obsolete and it needs to review,
however I haven't detailed information about it.
Martin Paljak:
> Hello Aleksey and others,
>
> Those of you who have used pkcs15init API, can anyone explain the way
> keycache works? There is some ex
Andreas Jellinghaus:
> Am Dienstag 06 Oktober 2009 10:17:08 schrieb Aktiv Co. Aleksey Samsonov:
>> I want to make a few changes to cleanup.
>> It takes me a few hours to do it.
>
> ok. no hurries, let me know when its done. a few days more or less
> before the nex
Aktiv Co. Aleksey Samsonov:
> Hello,
> Rutoken initialization failed after
> http://www.opensc-project.org/opensc/changeset/3765#file8
> $ pkcs15-init -l "Rutoken ECP User PIN" -a 02 --pin "12345678" --puk ""
> -P --so-pin "87654321&quo
Hello,
Pierre Ossman:
> On Mon, 5 Oct 2009 11:28:12 +0300
> Martin Paljak wrote:
>
>> On 05.10.2009, at 11:01, Pierre Ossman wrote:
>>> New attempt, this time against r3756 (r18006 was our internal repo,
>>> for
>>> those curious :)), as an attachment and without a signature on the
>>> mail. Hop
Hello,
Rutoken initialization failed after
http://www.opensc-project.org/opensc/changeset/3765#file8
only (trunk/src/pkcs15init/keycache.c)
Example:
$ pkcs15-init -E -C --so-pin "87654321" --so-puk ""
OK!
$ pkcs15-init -l "Rutoken ECP User PIN" -a 02 --pin "12345678" --puk ""
-P --so-pin "87654
Hello,
Andreas Jellinghaus:
> Am Samstag 03 Oktober 2009 10:05:37 schrieb Andreas Jellinghaus:
>> Hi,
>>
>> shall we create a new opensc 0.11.* release? things to wait for
>> before we create such a release?
>
> Aleksey commited the latest rutoken changes for GOST algorithm,
> I added the pending
Alon Bar-Lev:
> The pkcs11.h hank looks right.
>
> On Tue, Oct 6, 2009 at 8:08 AM, Andreas Jellinghaus
> wrote:
>>> When updating pkcs11.h, please sync with scut [1]
>>> Maintainer is at [2].
>> no worries, I will take care of that. is the patch ok
>> otherwise? then I will apply it.
Thanks ver
Hi,
Example (This is a circumstance worthy of being noted)
$ pkcs15-init -E -C ...
...
No PIN objects
...
Create DF
(Example PKCS15-AppDF: (rutoken_ecp.profile) acl = *=NONE,
DELETE=___CHV2___)
...
Create PIN
...
Create DF
(Example PKCS15-AODF: (rutoken_ecp.profile) acl = *=NEVER, READ=NONE,
UPD
Hi,
> shall we create a new openct release?
There are almost no changes, but I'm for release.
> since 0.6.17 trunk got bsd fixes and rutoken S support.
> anything else we should wait for before creating
> a new release?
Current trunk are working in RutokenS and RutokenECP tests.
Andreas J
f
Is this the problem?
And also, I set the correct value CKA_GOSTR3410PARAMS in next patch.
Thanks
Aktiv Co. Aleksey Samsonov:
> Hello!
> I propose a patch for add GOST R 34.10-2001 algorithm (only PKCS#11 for
> the present). PKCS#11 and GOST:
> ftp://ftp.rsasecurity.com/pub/pkcs/pkc
Hello!
I propose a patch for add GOST R 34.10-2001 algorithm (only PKCS#11 for
the present). PKCS#11 and GOST:
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30m1-d7.pdf
This patch is first step. If it OK, I'll do:
- cleanup code
- add support to tools (pkcs15-init pkcs15-tool pkcs1
Hello!
I propose a patch for src/libopensc/card-westcos.c if it's working.
src/libopensc/card-westcos.c:westcos_select_file:
309:case SC_PATH_TYPE_PATH:
apdu.p1 = 9;// Why is it needed? ("9" ?)
336:if (file_out != NULL) {
apdu.resp = buf;
Hello.
Martin Paljak:
> On 17.09.2009, at 10:51, Andreas Jellinghaus wrote:
>> also shall we create a new 0.11 release for the two new drivers
> Why not?
I think that's a great idea.
>> or go straight for a new 0.12 release?
> I think it can wait a bit and hope that maybe we can do more cle
Hi!
Martin Paljak:
> Privet,
>
> On 14.09.2009, at 14:57, Aktiv Co. Aleksey Samsonov wrote:
>> Patch for /branches/martin/0.12 revision 3732 is in attachment:
>> rollback check (ctx->debug >= level) in SC_FUNC_RETURN macro.
>> Martin, could you please add it
Hello.
BUG: serial->len is used uninitialized in
rtecp_card_ctl:SC_CARDCTL_GET_SERIALNR (src/libopensc/card-rtecp.c)
Could you please add attached patch?
Thanks
diff -u -r opensc-trunk-r3719/src/libopensc/card-rtecp.c
opensc-trunk-r3719_new/src/libopensc/card-rtecp.c
--- opensc-trunk-r3719/src
Hello!
Patch for /branches/martin/0.12 revision 3732 is in attachment: rollback
check (ctx->debug >= level) in SC_FUNC_RETURN macro.
Martin, could you please add it?
Thanks
diff -u -r 0.12-r3732/src/libopensc/log.h 0.12-r3732_new/src/libopensc/log.h
--- 0.12-r3732/src/libopensc/log.h 2009-0
Andreas Jellinghaus:
> I haven't checked myself, but someone told me
> that opensc trunk isn't compiling without openssl.
>
> can anyone check?
Version: 0.11.9-svn (trunk-r3720)
User binaries: /usr/local/bin
Configuration files: /usr/local/etc
XSL stylesheets:
Martin Paljak:
> On 11.09.2009, at 14:30, Aktiv Co. Aleksey Samsonov wrote:
>> Hello.
>> I propose a patch for src/libopensc/card-westcos.c to fix some
>> compiler warnings and coding style and remove code duplication, but
>> unfortunately I can't test it.
Hello.
I propose a patch for src/libopensc/card-westcos.c to fix some compiler
warnings and coding style and remove code duplication, but unfortunately
I can't test it.
Patch for trunk revision 3718.
Thanks
Andreas Jellinghaus:
Am Freitag 11 September 2009 08:47:38 schrieb François Leblanc:
Andreas Jellinghaus:
> I don't want to put __attribute__((unused)) everywhere to quiet gcc.
> Should we use -Wno-unused-parameters in configure when --enable-strict
> is added? that should quiet a lot of unreasonable warnings.
I believe that the only true way to quiet a lot of unreasonable warnin
François Leblanc:
> Hi there,
Hello.
> If someone can have a look and apply this patch or tell me correction to be
> made,
.
--- src/libopensc/cards.h (revision 3716)^M
+++ src/libopensc/cards.h (working copy)^M
@@ -148,6 +148,8 @@^M
SC_CARD_TYPE_ENTERSAFE_FTCOS_PK_01
Hello,
Patch for trunk revision 1163 is in attachment: Add support for Rutoken
S in etc/openct.fdi and etc/openct.udev.modalias.in.
Could you please add it?
Thanks
diff -u -r openct-trunk-r1163/etc/openct.fdi
new/openct-trunk-r1163/etc/openct.fdi
--- openct-trunk-r1163/etc/openct.fdi 2009-04-
Hello,
Andreas Jellinghaus:
> http://www.opensc-project.org/files/opensc/testing/opensc-0.11.9-pre1.tar.gz
>
> this preview has all the latest changes. please give it a try
> and let us know if it works for your, or what doesn't work.
This preview are working in RutokenS and RutokenECP tests.
Th
Hello,
Andreas Jellinghaus:
> are there other changes/patches/projects that I forgot
> and that need to be applied / need new releases too?
Could you please apply the pkcs15-rutoken.c and pkcs15-rtecp.c patches I
sent on 7/17/2009 to the next release?
Thanks
Hello,
Bug (Rutoken S, Rutoken ECP):
$ pkcs15-init -E -C
$ pkcs15-init -E -C
$ opensc-explorer
OpenSC [3F00]> cat 2f00
: 61 1F 4F 0C A0 00 00 00 63 50 4B 43 53 2D 31 35 a.O. ...cPKCS-15
0010: 50 09 52 75 74 6F 6B 65 6E 20 53 51 04 3F 00 50 P.Rutoken SQ.?.P
0020: 15 61 1F 4F 0C A0
Aktiv Co. Aleksey Samsonov:
Yes, this is not needed for linux, but ifd_scan_usb's in:
src/ifd/sys-bsd.c:533:
src/ifd/sys-bsd.c:597:
src/ifd/sys-solaris.c:572:
src/ifd/sys-sunray.c:347:
/* FIXME: if we don't find a driver with vendor/product
* then check for the interface type (cci
river = "ccid";
}
This patch need only for ifd_scan_usb ("openct-control init") in not linux.
Alon Bar-Lev:
> This is strange... As the default is ccid for all.
>
> On Fri, Jul 17, 2009 at 11:50 AM, Aktiv Co. Aleksey
> Samsonov wrote:
>&
Hello,
Andreas Jellinghaus:
> Am Donnerstag 16 Juli 2009 14:35:19 schrieb Aktiv Co. Aleksey Samsonov:
>> Could you please add patch for support Rutoken ECP tokens? (Patch for
>> trunk revision 1158 is in attachment) Thanks.
>
> Could you check the other files in etc/ dire
a driver with vendor/product
* then check for the interface type (ccid) and use
* driver ccid... */
> On Thu, Jul 16, 2009 at 3:35 PM, Aktiv Co. Aleksey Samsonov
> wrote:
>> Could you please add patch for support Rutoken ECP tokens? (Patch for trunk
>> revision 1158 is in atta
Hello,
Ludovic Rousseau:
It looks like your patch is correct. All the ICCD devices I know have
dwFeatures & 0x = 0x840.
Patch applied in revision 1158
Thanks!
Could you please add patch for support Rutoken ECP tokens? (Patch for
trunk revision 1158 is in attachment) Thanks.
diff -u -r o
Hello,
ISO/IEC 7816-12:2005
7.2 The Class Specific Descriptor
Table 8 - Class specific descriptor for a USB-ICC
Offset: 40
Field: dwFeatures
Size:4
Value: 00840h
0002 00840h
0004 00840h
Description:
The value of the lower word (=0840) indicates
t
Hello,
FIX: sc_get_rutoken_driver above EMV because the detection gets caught
there first.
Patch for trunk revision 3698 is in attachment. Could you please add it?
Thanks
diff -u -r opensc-trunk-r3698/src/libopensc/ctx.c
new/opensc-trunk-r3698/src/libopensc/ctx.c
--- opensc-trunk-r3698/src/lib
Ludovic Rousseau:
2009/6/23 Andreas Jellinghaus :
maybe we can obsolete some of those card specific implementations,
if the only difference was this value?
Maybe. I had a look at card-setcos.c and the two
iso7816_set_security_env() functions are very similar. And they are
even more similar wit
Hello,
Ludovic Rousseau:
maybe we can obsolete some of those card specific implementations,
if the only difference was this value?
Maybe. I had a look at card-setcos.c and the two
iso7816_set_security_env() functions are very similar. And they are
even more similar with the patch applied.
Any
Aktiv Co. Aleksey Samsonov:
Patches for trunk revision 3698 are in attachment.
Sorry for inconvenience caused.
Patches for trunk revision 3698 are in attachment.
diff -u -r opensc-trunk-r3698/src/libopensc/iso7816.c
new/opensc-trunk-r3698/src/libopensc/iso7816.c
--- opensc-trunk-r3698/src
Hello,
Ludovic Rousseau:
> 2009/6/23 Aktiv Co. Aleksey Samsonov :
>> I propose the attached patch for iso7816.c.
>
> Can you split the patch is small and independent patches please?
> And for each patch explain what the patch does and/or why it is needed.
>
> For ex
Ludovic Rousseau:
> 2009/6/24 Aktiv Co. Aleksey Samsonov :
>> Rutoken ECP:
>> P: Vendor=0a89 ProdID=0030 Rev= 1.00
>> S: Manufacturer=Aktiv
>> S: Product=Rutoken ECP
>
> It looks like the device is different from the one I have in my list
> "Rutoken Ma
Hello,
Andreas Jellinghaus:
> can you put this information into a wiki page?
> you need to login with your account and password before you
> can edit wiki pages / create new pages. if you don't have
> an account, please send me a private email with user/password
> and I will create one for you.
Y
Hi,
I implemented support (currently only RSA) Rutoken ECP tokens (in
Russian http://rutoken.ru/products/rutokends/) for OpenSC.
Worked: ccid-1.3.10 + pcsc-lite-1.5.4 (pcsc-lite-1.5.2) + opensc
Patch for trunk revision 3695 is in attachment.
Initialize:
$ pkcs15-init --erase-card --create-pkcs1
Hi,
I propose the attached patch for iso7816.c.
It looks like your patch is correct (according to ISO 7816-4 2003,
page 54, 7.5.11 MANAGE SECURITY ENVIRONMENT command)
Any objection from other list members?
almost every card driver has it's own set_security_env implementation,
so this change
Hi,
ISO 7816-4: 7.5.11 MANAGE SECURITY ENVIRONMENT command:
Table 78 - P1
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
- - - 1 - - - - Secure messaging in command data field
- - 1 - - - - - Secure messaging in response data field
- 1 - - - - - - Computation, decipherment, internal authentication and
key agr
Hi,
ISO 7816-4: 7.5.11 MANAGE SECURITY ENVIRONMENT command:
Table 78 - P1
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
- - - 1 - - - - Secure messaging in command data field
- - 1 - - - - - Secure messaging in response data field
- 1 - - - - - - Computation, decipherment, internal authentication and
key agre
Hi!
src/tools/opensc-tool.c:303:
const char *ac_ops_ef[] = {
"read", "update", "write", "erase", "rehab", "inval"
};
src/libopensc/opensc.h:92
/* Operations relating to access control (in case of DF) */
#define SC_AC_OP_SELECT 0
#define SC_AC_OP_LO
Hi!
cardos-tool.c: In function 'cardos_format':
cardos-tool.c:621: error: label 'erase_state' used but not defined
cardos-tool.c:779:
#ifdef ENABLE_OPENSSL
...
erase_state:
Thanks
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http
Alon Bar-Lev:
> 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?
The export of cryptography (GOST 28147-89)
Hello.
Andreas Jellinghaus:
> can you also edit the wiki page,
> and document what this change means for users?
I will try to do so.
> e.g. do people need to delete and re-initialize their tokens?
Yes. For example:
$pkcs15-init --erase-card
$pkcs15-init --create-pkcs15 --so-pin "87654321"
$pkcs
Is "ifdhandler" correct? (Not "openct.conf" or "openct.conf.new"?)
Alon Bar-Lev:
> Should be.
>
> On 1/29/09, Aktiv Co. Aleksey Samsonov wrote:
>> Hello.
>> The openct trunk revision 1127: configure.ac: Line 400:
>>
>>
Hello.
The openct trunk revision 1127: configure.ac: Line 400:
CPPFLAGS_OPENCT_CONF_PATH='-DOPENCT_CONF_PATH="\"$(sysconfdir)/ifdhandler\""'
- is it correct?
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.o
Alon Bar-Lev:
Can you please update the openct trunk so that Rutoken use the new
event interface?
OK, the updated patch is attached.
On 1/28/09, Alon Bar-Lev wrote:
Thanks.
Applied.
Thanks!
diff -u -r openct-0.6.15.trunk-r1127/src/ifd/ifd-rutoken.c
openct-0.6.15.trunk-r1127_new/src/ifd
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
bin0MSZ0ZoczJ.bin
Description: application/gzip
___
opensc-d
> not sure if they follow this mailing list.
pkcs11-tool for Rutoken S is not yet supported (have problems).
pkcs15-tool is supported (almost all options).
Andreas Jellinghaus:
> Hi Pavel,
>
> can you check with the rutoken authors?
> not sure if they follow this mailing list.
> I neither hav
Aktiv Co. Aleksey Samsonov:
> Examples:
> $ opensc-explorer
> OpenSC Explorer version 0.11.4-svn
> OpenSC [3F00]> cat
> only working EFs may be read
> OpenSC [3F00]> cat
> only working EFs may be read
> opensc-explorer: sc.c:492: sc_file_free: Assertion `sc_file_va
Patch opensc-0.11.4.trunk-r3502-fix-segv_print_tags_asn1.diff (for trunk
trunk revision 3502) is draft.
Example 1 (SIGSEGV):
OpenSC Explorer version 0.11.4-svn
OpenSC [3F00]> cd ff00
OpenSC [3F00/FF00]> asn1 0001
Printing tags for buffer of length 512
[Switching to Thread -1211906368 (LWP 25131
Patch opensc-0.11.4.trunk-r3498-fix_2free_osc-explorer.diff (for trunk
trunk revision 3502) is draft
Examples:
1)
$ opensc-explorer
OpenSC Explorer version 0.11.4-svn
OpenSC [3F00]> cat
only working EFs may be read
OpenSC [3F00]> cat
only working EFs may be read
opensc-explorer: sc.c:492: sc_fi
Alon Bar-Lev:
Do you sure you not require O_BINARY in rutoken-tool?
O_BINARY is non-standard flag, but for generality...
opensc-0.11.4.trunk-r3491-fix_msvc_o_binary.diff.gz
Description: application/gzip
___
opensc-devel mailing list
opensc-devel@lis
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210038592 (LWP 2240)]
0xb7e6e5b4 in memset () from /lib/tls/libc.so.6
(gdb) backtrace
#0 0xb7e6e5b4 in memset () from /lib/tls/libc.so.6
#1 0xb7f4c28e in ct_status_alloc_slot (num=0xbffaed24) at status.c:144
#2 0x0804a5
Alon Bar-Lev:
> So what caused the need to apply this in the first place?
I have not looked through change in winconfig.h.in and used
http://www.opensc-project.org/opensc/browser/trunk/src/tools/pkcs11-tool.c?rev=3489#L961
as a basis.
> Is there an issue to fix?
This is an attempt to solve a poss
Alon Bar-Lev:
> Committed at rev 3490.
Thanks!
> This is not required.
Right, current trunk is already true.
> Anyway it looks like it is required only for MSVC.
Yes, it's for MSVC only.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.o
Patch for trunk revision 3489 is in attachment.
opensc-0.11.4.trunk-r3489-fix_msvc_build.diff.gz
Description: application/gzip
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-dev
Alon Bar-Lev:
Much better!!!
Can you please rebase and send all your modifications as single patch?
Patch for trunk revision 3477 is in attachment.
opensc-0.11.4.trunk-r3477-0.11.4.trunk-r3477_rutoken-0.3.3.diff.gz
Description: application/gzip
___
Alon Bar-Lev:
Patch opensc-0.11.4.trunk-r3476_rutoken-0.3.2_2.diff (for
opensc-0.11.4.trunk-r3476-0.11.4.trunk-r3476_rutoken-0.3.2.diff)
is draft. This patch solves the problem with exported functions. (Instead of
pkcs15-prkey-rutoken.c it'll be rutoken-prkey.h). If this solution is better
than
On Fri, Apr 11, 2008 at 11:40 AM, Aktiv Co. Aleksey Samsonov wrote:
We are going to release tested patch for the current version of your code
in a couple of days. It fixes a number of bugs in Rutoken code and changes
card-rutoken.c file to meet OpenSC coding standards.
Patch for trunk
88 matches
Mail list logo
