Commit Graph

26 Commits

Author SHA1 Message Date
Frank Morgner 89f9d9e85d add compatibility implementation for strnlen
fixes https://github.com/OpenSC/OpenSC/issues/660
2016-01-20 10:47:27 +01:00
Frank Morgner 8e7049c2fa removed unused variables 2015-10-30 18:21:40 +01:00
Frank Morgner 5b0332528f fixed accessing app_label in sc_pkcs15_data_info_t 2015-10-05 08:23:02 +02:00
Viktor Tarasov 18e962942b pkcs15-data: fix memory leakage 2015-05-08 09:10:47 +02:00
Frank Morgner bcb5fc15e5 honour HAVE_CONFIG_H 2015-04-22 23:55:33 +02:00
Frank Morgner a3fc62f79f fixed NULL dereference (or warning thereof) 2015-02-05 01:38:40 +01:00
Frank Morgner a64326e768 fixed compiler warnings (partially submitted)
Signed-off-by: Frank Morgner <morgner@informatik.hu-berlin.de>

PR-222: commit 0b567dbaa8
partially submitted by Viktor Tarasov
2014-05-03 21:47:15 +02:00
Viktor Tarasov 743ca1cedc pkcs15: new 'data' member in 'sc_pkcs15_data_info'
New member keeps the value of the PKCS#15 DATA object.

Internal pkcs15 procedure that reads DATA object is modified
to check if requested data are already vailable in 'data-info',
an only then try to read the content of dedicated on-card file.

For some emulated PKCS#15 systems value of DATA object is kept as 'direct' value
in a proprietary attribute files and so the common read procedure could not be used.

; some efforts to unify layout of code source.
2013-03-11 13:04:10 +01:00
Viktor Tarasov 58b4304957 libopensc: 'init', 'format', 'compare', 'is-valid' OID procedures
In a reason of number of bugs(*) that concern the OID management,
the general usage OID procedures 'init', 'format', 'compare', 'is-valid' are introduced.
These procedures should be used by all actors: libopensc, pkcs15, pkcs11, tools, ....

(*)
This bug reported by Andreas Schwier :
8e75d971cb (commitcomment-1792477)

In pkcs15-algo sc_asn1_get_algorithm_info() can return the OID without ending '-1's:
https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/pkcs15-algo.c#L452
https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/pkcs15-algo.c#L459
2012-09-06 10:47:29 +02:00
Viktor Tarasov 9d5404bac6 libopensc: some usefull macros, crc32 calculation procedure
Introduce some usefull define macros, error code 'inconsistent configuration'.
Introduce procedure to calculate CRC32 digest,
to be used in minidriver to calculate the 'freshness' values.
2012-05-29 11:29:44 +02:00
andre a9eba2b205 libopensc: Remove unused parameter 'file_out' in function 'sc_pkcs15_read_file'.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@5546 c6295689-39f2-0310-b995-f0e70906c6a9
2011-06-05 11:08:36 +00:00
vtarasov e7790508f6 pkcs15: when setting object data's path, use, if available, the AID from 'DiscretionaryDataObject'
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@5111 c6295689-39f2-0310-b995-f0e70906c6a9
2011-01-18 16:31:41 +00:00
ludovic.rousseau f47416d60e Do not cast the return value of malloc(3) and calloc(3)
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
2010-08-18 15:08:51 +00:00
aj 6545b42c02 cleanup of the debug code:
* reduce to a few, supported functions.
* change all functions to take the debug level as parameter.
* use symbolic names for the debug levels.
* fix tools to pass "verbose"/"opt_debug" as ctx->debug.


git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@4118 c6295689-39f2-0310-b995-f0e70906c6a9
2010-03-15 12:17:13 +00:00
aj d22a2483c0 Header file cleanup.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@4081 c6295689-39f2-0310-b995-f0e70906c6a9
2010-03-04 08:14:36 +00:00
henryk b45617c451 Make absolute paths from all paths read from the PKCS#15 directories by prepending the DF(PKCS#15) path if necessary.
Fixes compatibility with Siemens HiPath SIcurity formatted cards which use relative paths.


git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@3028 c6295689-39f2-0310-b995-f0e70906c6a9
2006-09-26 10:55:02 +00:00
nils e8c05ca648 use more opensc specific names for ASN.1 tags to avoid name conflicts
with other ASN.1 libraries


git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@2815 c6295689-39f2-0310-b995-f0e70906c6a9
2006-01-20 20:52:36 +00:00
nils 23802d825e properly initialize sc_asn1_entry elements + some cleanup
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@2463 c6295689-39f2-0310-b995-f0e70906c6a9
2005-08-05 07:24:43 +00:00
bert 2d97002824 API fixup: use defined type instead of struct for exposed structs
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@2232 c6295689-39f2-0310-b995-f0e70906c6a9
2005-03-08 20:59:35 +00:00
nils 8673508a43 fix memory leak, cleanup: use object specific release method
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@2024 c6295689-39f2-0310-b995-f0e70906c6a9
2004-12-18 14:14:57 +00:00
nils 395c614483 fix default values for OIDs
patch supplied by Victor Tarasov <vtarasov@idealx.com>


git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@1866 c6295689-39f2-0310-b995-f0e70906c6a9
2004-07-23 20:29:05 +00:00
aet 5616dba08e - Stop using unflexible automake conditionals when
building PC/SC, OpenCT or USBToken support,
  use ifdef's directly in source.
- Because of above, add HAVE_PCSCLITE for winconfig.h
- Remove unnecessary includes for log.h, opensc.h and
  errors.h in libopensc sources, they're already taken
  care by internal.h.


git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@1406 c6295689-39f2-0310-b995-f0e70906c6a9
2003-09-03 09:28:55 +00:00
sth 093adc8c89 Fix: don't DER-en/decode the data in a pkcs15 object
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@1385 c6295689-39f2-0310-b995-f0e70906c6a9
2003-08-20 14:15:02 +00:00
aet b1eff66867 C++ warning fixes (assuan excluded)
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@863 c6295689-39f2-0310-b995-f0e70906c6a9
2003-01-14 19:55:45 +00:00
okir a7615abdeb - attempt to fix DODF encoding/decoding
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@798 c6295689-39f2-0310-b995-f0e70906c6a9
2002-12-19 14:26:54 +00:00
okir b86d2e994b - First shot at pkcs15 data objects from Danny De Cock
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@788 c6295689-39f2-0310-b995-f0e70906c6a9
2002-12-18 10:17:01 +00:00