Hello,
2010/12/9 Martin Paljak :
> Hello,
> On Dec 9, 2010, at 9:23 AM, webmas...@opensc-project.org wrote:
>
>> Revision: 4930
>> Author: s
>> Date: 2010-12-09 07:23:10 + (Thu, 09 Dec 2010)
>>
>> Log Message:
>> ---
>> add to r4904: fix calculating of signature size for CKK_GOST
Hello,
Douglas E. Engert wrote:
> Great for now. But in SVN pkcs15-sec.c:188,189:
>
> 187 switch (obj->type) {
> 188 /* FIXME -DEE GOSTR is misusing the sc_card_find_rsa_alg */
> 189 case SC_PKCS15_TYPE_PRKEY_GOSTR3410:
> 190 case SC_PKCS15_TYPE_PRKEY_RSA:
> 191
Hello,
2010/11/30 Douglas E. Engert :
> On 11/29/2010 4:36 AM, Aleksey Samsonov wrote:
>> After fix it, I have fail in my tests with GOSTR (PKCS#11 C_Sign).
>> Unfortunately, I don't have logs now.
>
> One thing to look at:
>
> In pkcs15-sec.c in sc_pkcs15_compute
Hello,
One remark. We need use 'include ' for use OPENSSL_NO_EC.
Сomplete example (or see src/pkcs11/openssl.c):
#include /* for OPENSSL_VERSION_NUMBER */
#if OPENSSL_VERSION_NUMBER >= 0x1000L
#include
#include /* for OPENSSL_NO_* */
#ifndef OPENSSL_NO_EC
#include
#endif /* OPENSSL_NO_EC
Hello Douglas,
2010/11/23 Douglas E. Engert :
> I would especially like the GOSTR maintainers to look at this closely, as many
> of the flag tests and if statements where modified to support EC and hopefully
> make it easier to add algorithms in the future.
There have compile error at libopensc/p
Hello,
2010/11/22 Andre Zepezauer :
> On Mon, 2010-11-22 at 09:12 -0600, Douglas E. Engert wrote:
>> If a card can support chaining (CLA=10), then it can use 2048 bit keys
>> with these readers.
>
> The same is true for the ENVELOPE command. Nevertheless there is a large
> fraction of cards that w
Hello Andre,
Andre Zepezauer wrote:
> Hello Aleksey,
>
> I really hope that it isn't a huge disaster for your personal life, when
> support for "Rutoken S" will be dropped in the near future. The rational
> behind this decision may be the fact, that such a kind of device is
> technology from the
Hello,
Martin Paljak wrote:
> On Sep 1, 2010, at 9:41 AM, Aleksey Samsonov wrote:
>> "Rutoken S" [1] doesn't support on-board RSA (as opposed to "Rutoken ECP").
>> "Rutoken ECP" [2] have on-board RSA (with RSA keys up to 2048 bits), GOST R
>
Hello,
Martin Paljak wrote:
> On Aug 30, 2010, at 2:52 PM, Emanuele Pucciarelli wrote:
>>> The handful of drivers with insecure operations I was talking about, I
>>> got with the following command: grep -n OPENSSL libopensc/card-*.c
>>>
>>> But looking closer to each drivers source, I must confess
Hello,
Martin Paljak wrote:
>> 2. The announcement of the GOST public key algorithm seems to me very
>> optimistic. Because the current implementation isn't functional at all
>> [1][2].
> Good catch.
The GOST public key algorithm is working (the current implementation),
but in [1] [2] by a lucky
Hello,
Aleksey Samsonov wrote:
>>> martin, do you want to create new releases?
>> Need to test 0.11 branch with the openssl engine fix.
>
> Could you wait a few days? I'm try to find more clean solution. We have
> problem under the stipulation that lo
Hello,
Martin Paljak wrote:
>> * what happend to opensc 0.11.*? I thought the problem with
>> gost / engine_pkcs11 is so big, it should be fixed in
>> the 0.11 line to help normal users, and so distributions
>> can backport that fix if they want.
> Apparently Jean-Michel has some specific bugfi
Hello,
Fix committed to trunk (revision 4347). Could you please test it?
Thanks
Aleksey Samsonov wrote:
> Hello,
>
> Martin Paljak wrote:
>> Hello,
>>
>> On Apr 22, 2010, at 23:08 , Aleksey Samsonov wrote:
>>
>>> What are you think about solution in
Hello,
Martin Paljak wrote:
> Hello,
>
> On Apr 22, 2010, at 23:08 , Aleksey Samsonov wrote:
>
>> What are you think about solution in attachment? (openssl.cnf isn't needed
>> in this case)
>> Thanks
>> Index: src/pkcs11/openssl.c
>>
>
Hello,
Jan Just Keijser wrote:
Hi Martin,
Martin Paljak wrote:
On Apr 22, 2010, at 00:25 , Jan Just Keijser wrote:
Hi Andreas,
Andreas Jellinghaus wrote:
hmm. if we had only one engine doing both rsa and gost, the
problem would be gone, without this "hack" required in opensc?
my po
Hello,
Jan Just Keijser wrote:
Martin Paljak wrote:
On Apr 16, 2010, at 09:51 , Aleksey Samsonov wrote:
I commented out the OPENSSL_config(NULL) and now it works ...
should this added as a patch? the FIXME seems to be to *remove* the
explicit call to OPENSSL_config; I can confirm that
Hello,
Call OPENSSL_config(NULL) was need for loading GOST engine. It was need
for applications which use PKCS#11 (opensc-pkcs11.so) with GOST
algorithms and which don't use openssl directly (not call
OPENSSL_config(NULL)).
Jan was right, he wrote more detailed:
Jan Just Keijser wrote:
> the
Hello,
Andreas Jellinghaus wrote:
> Am Freitag 16 April 2010 08:51:31 schrieb Aleksey Samsonov:
>> Hello,
>>
>> Jan Just Keijser wrote:
>>> in opensc-0.11.13/src/pkcs11/openssl.c there's section
>>>
>>> 106 void
>>> 107 sc_pkcs11_re
Hello,
Jan Just Keijser wrote:
> in opensc-0.11.13/src/pkcs11/openssl.c there's section
>
> 106 void
> 107 sc_pkcs11_register_openssl_mechanisms(struct sc_pkcs11_card *card)
> 108 {
> 109 #if OPENSSL_VERSION_NUMBER >= 0x1000L
> 110 /* FIXME: see openssl-1.0.0-beta3/engines/ccgost/README.g
Hello Andreas,
Thank you for your work!
Good luck Martin!
Andreas Jellinghaus wrote:
> Dear all,
>
> for several years I have coordinated the OpenSC, OpenCT, Libp11,
> Pam_p11 and Engine_PKCS11 projects: Created new releases, fixed
> some bugs, helped many users with questions, applied patches
>
Hello Viktor,
Viktor TARASOV wrote:
> rv = sc_change_reference_data(card, pin_info->type, pin_info->reference, ...
>
> My humble question is: does there any mis-usage of the 'type' member of
> the 'pin_info' data?
>
> Afaik,
> 'type' in 'sc_pkcs15_pin_info' structure holds the PKCS#15
> PinAt
Martin Paljak wrote:
> On Feb 15, 2010, at 19:04 , Aleksey Samsonov wrote:
>> Сhangeset r4027 and r4028. What do you think?
> Leaks are bugs. Yes.
Andreas Jellinghaus wrote:
> they look like nice clean bug fixes, so they make
> good candidates for the 0.11.13 release. fee
Hi,
Andreas Jellinghaus wrote:
> so is everything we want for 0.11.13 commited?
Сhangeset r4027 and r4028. What do you think?
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-deve
Hello,
Andreas Jellinghaus wrote:
> Thanks to Stephan Hermann new openct and opensc
> packages for ubuntu are available:
>
> https://launchpad.net/ubuntu/+source/openct/0.6.19-1ubuntu2
> https://launchpad.net/ubuntu/+source/opensc/0.11.12-1ubuntu1
>
> To my knowledge they contain all the changes
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
> CK_MECHANISM gostMech = { CKM_GOSTR3410_KEY_PAIR_GEN, NULL, 0 };
> ...
> C_GenerateKeyPair(hSession, &gostMech, NULL_PTR, 0, NULL_PTR, 0,
> &hPubKey, &hPrvKey);
> -> CKR_OK and RSA Key Pair
Fix at trunk revision 3887(+3888)
But
CK_MECHANISM pMech = { CKM_RSA_PKCS_KEY_PAIR_GEN, NULL, 0 };
...
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 wrote:
> For now I propose this small patch to permit "generate_key" with pkcs11-tool.
More universal (but not full and not good for future) patch is here:
http://www.opensc-project.org/pipermail/opensc-devel/2009-November/012863.html
__
Hello,
Viktor TARASOV wrote:
> Aleksey Samsonov wrote:
>> Thanks, but some potencial memory leaks. See patch in attachment.
>
> You can apply this patch, if you think it should be.
ok
> As for me, there is no potential leaks -- I trust entirely the
> sc_asn1_encode() .
&g
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,
Viktor TARASOV wrote:
Aktiv Co. Aleksey Samsonov wrote:
Viktor TARASOV:
It's commited ...
Thanks, but some remarks:
Potencial memory leaks (see /* */):
Thanks for your code revision.
Thanks, but some potencial memory leaks. See patch in attachment.
Index: src/pkcs15init/p
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:
>>> Aktiv Co. Aleksey Samsonov wrote:
>>>> Viktor TARASOV:
>>>
>>>>> It's commited ...
Thanks, good work.
--- /trunk/src/libopensc/pkcs15-pubkey.c (revision 38
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
Aleksey Samsonov wrote:
>> Does it exists any rule for the assigning of the debug level for debug
>> messages ?
>
> I think we have to follow common sence.
>
Also you can find some information here
http://www.opensc-project.org/pipermail/opensc-devel/2009-
Hello,
Viktor TARASOV wrote:
> Hi,
>
> my general question is:
> will you agree to have a little bit more of the debug messages in the
> common sources ?
> IMHO, it will facilitate the debugging and the comprehension of the 'how
> it works'.
If it is useful, yes.
> I mean, at least, to use m
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
Kalev Lember wrote:
> On 10/23/2009 06:10 PM, Aktiv Co. Aleksey Samsonov wrote:
>> -> #define OPENSSL_NO_EC
>> Right?
>> It is my bug.
>> Thanks!
>
> Yes, OPENSSL_NO_EC is defined in there. Thanks for taking a look
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,
Andreas Jellinghaus wrote:
> Am Mittwoch 07 Oktober 2009 11:34:36 schrieb Aktiv Co. Aleksey Samsonov:
>> I think, we need to rollback:
>
> propably the best idea.
> the old code was working, I don't understand why the new code is
> necessary (ok, I don'
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
Hello,
Patch applied in revision 3757.
Aleksey Samsonov wrote:
> 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.
Hello,
Martin Paljak wrote:
>
> On 03.10.2009, at 15:19, Aleksey Samsonov wrote:
>
>> Hello,
>> Martin, could you explain please what for we need this change?
>> http://www.opensc-project.org/opensc/changeset/3752/branches/martin/0.12/src/libopensc/apdu.c
>>
Hello,
Martin, could you explain please what for we need this change?
http://www.opensc-project.org/opensc/changeset/3752/branches/martin/0.12/src/libopensc/apdu.c
if SC_APDU_CASE_3_SHORT and apdu->datalen == 0 and
apdu->lc == 0 then no error? Why?
Thanks
__
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
Hello,
In trunk revision 1168 and 1167 I corrected openct/etc/Info.plist
according to openct.conf.
Hope it won't entail any side effects, please check it.
Thanks
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-proje
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
1 - 100 of 125 matches
Mail list logo
