sc_pkcs15_cert now has pointer to sc_pkcs15_pubkey, allowing it to
be removed and used separatly.
sc_pkcs15_pubkey now has pointer to sc_algorithm_id to faclitate
addition of other key algorithms and their parameters.
Various code changes to free these structures and references
to the structures have been changed.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@4805 c6295689-39f2-0310-b995-f0e70906c6a9
Assuming the driver has correctly set max_tries to 1 then PKCS#11 is very clear about it:
"""
True if supplying an incorrect user PIN will it to become locked.
"""
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@4687 c6295689-39f2-0310-b995-f0e70906c6a9
Support for importing cleartext keys is left untouched, but all transparent key generation by either opensc-pkcs11.so or pkcs15-init is removed, to make the operation with cleartext keys visible to the user and his explicit wish.
OpenSC is a PKCS#11 library for accessing keys protected by a smart card. Key material in software is not protected by smart cards and can leave a false sense of security to the user.
http://www.opensc-project.org/pipermail/opensc-devel/2010-April/013877.html
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@4646 c6295689-39f2-0310-b995-f0e70906c6a9
From http://en.wikipedia.org/wiki/Malloc#Casting_and_type_safety
" Casting and type safety
malloc returns a void pointer (void *), which indicates that it is a
pointer to a region of unknown data type. One may "cast" (see type
conversion) this pointer to a specific type, as in
int *ptr = (int*)malloc(10 * sizeof (int));
When using C, this is considered bad practice; it is redundant under the
C standard. Moreover, putting in a cast may mask failure to include the
header stdlib.h, in which the prototype for malloc is found. In the
absence of a prototype for malloc, the C compiler will assume that
malloc returns an int, and will issue a warning in a context such as the
above, provided the error is not masked by a cast. On certain
architectures and data models (such as LP64 on 64 bit systems, where
long and pointers are 64 bit and int is 32 bit), this error can actually
result in undefined behavior, as the implicitly declared malloc returns
a 32 bit value whereas the actually defined function returns a 64 bit
value. Depending on calling conventions and memory layout, this may
result in stack smashing.
The returned pointer need not be explicitly cast to a more specific
pointer type, since ANSI C defines an implicit conversion between the
void pointer type and other pointers to objects. An explicit cast of
malloc's return value is sometimes performed because malloc originally
returned a char *, but this cast is unnecessary in standard C
code.[4][5] Omitting the cast, however, creates an incompatibility with
C++, which does require it.
The lack of a specific pointer type returned from malloc is type-unsafe
behaviour: malloc allocates based on byte count but not on type. This
distinguishes it from the C++ new operator that returns a pointer whose
type relies on the operand. (see C Type Safety). "
See also
http://www.opensc-project.org/pipermail/opensc-devel/2010-August/014586.html
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@4636 c6295689-39f2-0310-b995-f0e70906c6a9
==21111== 1,360 (120 direct, 1,240 indirect) bytes in 1 blocks are definitely lost in loss record 107 of 109
==21111== at 0x4C24F0D: realloc (vg_replace_malloc.c:476)
==21111== by 0x409D23: sc_pkcs11_register_mechanism (mechanism.c:44)
==21111== by 0x410595: pkcs15_bind (framework-pkcs15.c:3160)
==21111== by 0x4085DD: card_detect (slot.c:214)
==21111== by 0x408887: initialize_reader (slot.c:114)
==21111== by 0x404C50: C_Initialize (pkcs11-global.c:247)
==21111== by 0x4034C9: main
==21111==
==21111== LEAK SUMMARY:
==21111== definitely lost: 120 bytes in 1 blocks
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@4388 c6295689-39f2-0310-b995-f0e70906c6a9
example:
int main()
{
C_Initialize(NULL);
C_Finalize(NULL);
return 0;
}
==4625== 592 (504 direct, 88 indirect) bytes in 1 blocks are definitely lost
in loss record 9 of 10
==4625== at 0x4C24137: calloc (vg_replace_malloc.c:418)
==4625== by 0x407FD9: create_slot (slot.c:80)
==4625== by 0x40452C: C_Initialize (pkcs11-global.c:243)
==4625== by 0x40342A: main
==4625==
==4625== 4,736 (4,032 direct, 704 indirect) bytes in 8 blocks are definitely
lost in loss record 10 of 10
==4625== at 0x4C24137: calloc (vg_replace_malloc.c:418)
==4625== by 0x407FD9: create_slot (slot.c:80)
==4625== by 0x408102: initialize_reader (slot.c:108)
==4625== by 0x4044E0: C_Initialize (pkcs11-global.c:247)
==4625== by 0x40342A: main
==4625==
==4625== LEAK SUMMARY:
==4625== definitely lost: 4,536 bytes in 9 blocks
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@4386 c6295689-39f2-0310-b995-f0e70906c6a9
martin
dengert
viktor.tarasov
ludovic.rousseau
s
alonbl