Use __FUNCTION__ as defind in log.h so will compile with any compiler.
logprint additional handles as size_t
Add check in reader-pcsc.c pcsc_user_reader for minidriver only.
On branch minidriver-5
Changes to be committed:
modified: src/libopensc/reader-pcsc.c
modified: src/minidriver/minidriver.c
Add MD_FUNC_CALLED(pCardData, level) and MD_FUNC_RETURN(pCardData, level, ...)
macros.
Handles are type __int3264 in VS2015 are casted as size_t when printing so
all bytes are printed. size_t on Windows are also treated as 32 or 64 bits.
SC_FORMAT_LEN_SIZE is used in the format.
(Works with VS2105 needs to be tested on other platforms.)
On branch minidriver-4
Changes to be committed:
modified: minidriver.c
Minidriver.c and reader-pcsc.c - reuse OpenSC reader structure
Windows CNG is managing the insertion and removal of the reader and the card
and will call CardAcquireContext and CardDeleteContext as needed if
the card or reader change. But different processes or threads may establish
different PCSC connects to the same reader and card but with different handles.
Reuse the OpenSC reader when windows uses the same reader but with different
handles. Tests show the certutil -v -scinfo works the same.
Associate_card is only need when called from
CardAcquireContext and disassociate_card is only need when called from
CardDeleteContext.
No need to call reinit_card_for(pCardData, name) just because the handles changed.
This may be the fix for #1763 because calls like CardCreateContainerEx remain
in card state rather then being lost when the handles changed.
Changes to be committed:
modified: src/libopensc/reader-pcsc.c
modified: src/minidriver/minidriver.c
The EC Parameters are the way the EC curve is presented to the outside world,
and in most cases is present in a matching certificate in the SPKI.
card-openpgp.c is modified to add the EC named_curve to the PKCS15 public key.
OpenPGP specs only provide this via the "Algorithm Attributes" for the 3 keys
via tags C1, C2 and C3 These contain the OID (not DER encoded) for the EC curve.
PKCS15 has two ways to encode a "pubkey" as it was originally written for RSA.
But other algorithms have parameters. X509 certificates encode the public key
in the SPKI and PKIX requires the parameters to be in the SPKI. PKCS15
allows for using a SPKI as source for a public key.
pgp_get_pubkey_pem will return the DER encoded RSA pubkey as before by
calling sc_pkcs15_encode_pubkey
pgp_get_pubkey_pem will return the DER encoded EC pubkey with parameters by
calling sc_pkcs15_encode_pubkey_as_spki which calls sc_pkcs15_fix_ec_parameters
internally to map DER encoded OID to named_curve.
For readability, "sc_pkcs15_pubkey_t pubkey;" definitions are changed to
"sc_pkcs15_pubkey_t p15pubkey;"
sc_pkcs15_erase_pubkey is used to avoid memory leaks.
On branch openpgp-ec-pub-curve
Date: Tue Jan 21 09:43:56 2020 -0600
Changes to be committed:
modified: src/libopensc/card-openpgp.c
- turns out, you can shrink a buffer with realloc on some implementations
- realloc is never called with 0 (which would free the data)
- length checking is done in zlib, we just do the allocation
closes https://github.com/OpenSC/OpenSC/issues/1905
In pre-v3 cards, it is hard-coded to 254 bytes.
In v3+ cards, it is stored in the "extended capabilities" DO 00C0.
Make the determined size available as a variable in the driver data.
* OpenPGP v3 increased the size for private DOs. Adapt to it.
* Use the symbolic constant from the refactored OpenPGP driver
instead of relying on magic numbers.
- turns out, you can shrink a buffer with realloc on some implementations
- realloc is never called with 0 (which would free the data)
- length checking is done in zlib, we just do the allocation
closes https://github.com/OpenSC/OpenSC/issues/1905
- remove command line option '--card-driver';
- instead force driver 'dnie' and fail if card is not a DNIe card
- overhaul option parsing
- remove unused variable 'long_optind'
- bail out with usage message on all unknown/unhandled args
- correctly terminate option parsing (no infinite loop)
- slight refactoring
- avoid magic constant '0x0f'
- make variable 'tries_left' more local
- move dependent code into if block
- remove command line option '--card-driver';
- instead force driver 'cardos' and fail if card is not a CardOS card
- overhaul option parsing
- remove unused variable 'long_optind'
- bail out with usage message on all unknown/unhandled args
- correctly terminate option parsing (no infinite loop)
- remove command line option '--card-driver';
- instead force driver 'PIV-II' and fail if card is not a PIV card
- overhaul option parsing
- remove unused variable 'long_optind'
- make work option '--reader' ( "r:" was missing in the optstring!!!)
- bail out with usage message on all unknown/unhandled args
- correctly terminate option parsing (no infinite loop)
Rename option '--driver' to '--card-driver' for increased consistency.
In addition, extend it the same way opensc-explorer was extended. I.e.
treat the question mark given as argument to option '--card-driver'
special: list all available drivers instead of stupidly bailing out.
In contrast to opensc-tool and opensc-explorer, which are card-agnostic,
I am not sure whether the option '--card-driver' makes sense on this
card-specific tool.
Extend cardos-tool the same way opensc-explorer was extended. I.e.
treat the question mark given as argument to option '--card-driver'
special: list all available drivers instead of stupidly bailing out.
In contrast to opensc-tool and opensc-explorer, which are card-agnostic,
I am not sure whether the option '--card-driver' makes sense on this
card-specific tool.
Extend piv-tool the same way opensc-explorer was extended. I.e.
treat the question mark given as argument to option '--card-driver'
special: list all available drivers instead of stupidly bailing out.
In contrast to opensc-tool and opensc-explorer, which are card-agnostic,
I am not sure whether the option '--card-driver' makes sense on this
card-specific tool.
Charlène
Jakub Jelen
Frank Morgner
Doug Engert
Lewis Porter
Raul Metsma
Peter Marschall
Liam Dawson