Opensc: Towards 0.16.0

[viktorTarasov]

I think it's time to prepare and publish the next major release.
The 0.16.0-pre1 is already created, so, let us continue this initiative.

I propose the end of the next week as a limit date to close (or to decide to postpone) the pending issues and PRs, or other issues that are not yet published.
And so, create first RC at the beginning of the week after next .

What will you say?

[dengert]

I will be on vacation next week, reading e-mail but can not test anything till 3/8/2016.

What changes are you expecting to add between now and then?

On 2/24/2016 7:46 AM, viktorTarasov wrote:

I think it's time to prepare and publish the next major release.
The 0.16.0-pre1 is already created, so, let us continue this initiative.

I propose the end of the next week as a limit date to close (or to decide to postpone) the pending issues and PRs, or other issues that are not yet published.
And so, create first RC at the beginning of the week after next .

What will you say?

—
Reply to this email directly or view it on GitHub https://github.com/OpenSC/OpenSC/issues/688.

Douglas E. Engert [email protected]

[viktorTarasov]

@dengert: ... can not test anything till 3/8/2016.

• there is no strict release schedule;
• until your date there will not be RC to test -- this period is to fix what has to be fixed/merged/.. into _master_ before RC.

@dengert: What changes are you expecting to add between now and then?

From my side, for this period, there is no changes that are not currently in _master_ ;
will try to resolve the existing PRs and issues, and see if there will be requests to include something else before train departure.

[frankmorgner]

1. Someone (else) should go through all defects reported by Coverity scan. I started to resolve them here
   https://github.com/OpenSC/OpenSC/pull/676, but there are still many new issues since the last release
2. Unfortunately I can't make much progress on #611. Everything is fine and tested on Linux since last year. However, on Windows there seems to be an invalid free on card->applications on opensc.dll which I have no idea of how to fix (the memory address equals the allocated one and it has not been free'd before). I am suspecting a Windows specific dll-loading problem... Any help would be appreciated.

[viktorTarasov]

Think that after decision about #705 and #704 the first RC of 0.16.0 will be created.

If you need to have resolved in next release the issues/PRs of middle complexity,
that have not been discussed recently -- it's time to mention them.

During this period will be fixing the evident coverity-scan issues.

[frankmorgner]

For inclusion to the upcoming release, I extracted the generic features of https://github.com/OpenSC/OpenSC/pull/611 into https://github.com/OpenSC/OpenSC/pull/706

[frankmorgner]

https://github.com/OpenSC/OpenSC/pull/694 should also be looked at for the next release. It still could need some improvements, as discussed in https://github.com/OpenSC/OpenSC/pull/655, but it works for now. @viktorTarasov could you have a look?

[viktorTarasov]

@frankmorgner

could you have a look?

No, if it do not concern the common part,
or, maybe, as a last priority task.

[dengert]

@viktorTarasov @frankmorgner

The removal of the hot-plug slot, with #687 #704 renumbers the slots.

This could surprise many users who have scripts expecting to use --slot 1 or slot_1
and now have to use --slot 0 or slot_0 (or don't use the parameter if there is only one reader.)

[viktorTarasov]

I understand, but:

• hot plug do not work in all cases (not when inserted more then one token);
• I do not get answer for question: when hot-plug is needed -- FF works as expected without it.
• as for me, slot reserved for hot-plug, first in the list, in default configuration -- it's not normal.

[dengert]

I am not saying to keep the hot-plug. But the user experience will change and this should be documented.

On 3/18/2016 12:59 PM, viktorTarasov wrote:

I understand, but, as for me:

• hot plug do not work in all cases (not when inserted more then one token);
• I do not get answer for question: when hot-plug is needed -- FF works as expected without it.
• as for me, slot reserved hot-plug, first in the list, in default configuration -- it's not normal.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub https://github.com/OpenSC/OpenSC/issues/688#issuecomment-198472557

Douglas E. Engert [email protected]

[viktorTarasov]

RC1 is ready to be tested. (Also on sourceforge)

Some auxiliary files still need to be finalized:

• _Release notes_;
• _NEWS_ -- _TODO_ section contains list of commits to be mentioned or not in NEWs;
• XML doc sources for some tools (from recent PRs)

[viktorTarasov]

OK tests RC1:

• IAS/ECC (Gemalto) with secure-messaging:
  
  
  
  • pkcs15 tools:
  
  
  • erase applications;
  
  
  • import, generation of keys, certificates into generic and protected applications;
  
  
  • sign, decrypt with key in generic and protected applications;
  
  
  • verify, change, unblock of PIN and SignPIN;
  
  
  • list and get PKCS15 objects.
  
  
  • pkcs11 :
  
  
  • with FF and icedove/thunderbird, linux/Win-Vista
    
    
    
    
    
    • generate key/import certificates Sign and Auth, import Encr pkcs12;
    
    
    
    • authentication, mail signature and encryption.
    
    
    
  
  
  • minidriver (with candidate to RC2 that includes #728):
  
  
  • with IE and Microsoft Windows Mail:
    
    
    
    
    
    • X509 Enrollment - generate key, import cert;
    
    
    
  
  
  • authentication, mail signing, mail decryption.
  
  
  • TODO: Import PKCS12
  
  
• 'CardOS v4.3B', 'Cryptoflex 16k', 'SetCOS 4.4.1 B'
  
  
  
  • pkcs15 tools:
  
  
  • re-initialize;
  
  
  • generate RSA-1024 key, import pksc12;
  
  
  • sign data, get pub. key
  
  
  • verify, change UserPIN
  
  
  • decrypt ('SetCOS 4.4.1 B')
  
  
• Oberthur: 'AuthentIC v3.2.2', 'Cosmo-64 v5.1', 'ePass 2003':
  
  
  
  • pkcs15 tools:
  
  
  • re-initialize;
  
  
  • generate RSA key, import pksc12;
  
  
  • get cert, pub. key
  
  
  • sign, decrypt
  
  
  • verify, change UserPIN
  
  

[dengert]

@viktorTarasov When do you plan to merge opensc-0.16.0 branch into master?
I note that your #728 hits 36 modules and is based on master. The longer we keep separate branches the harder it will be to merge them.

[viktorTarasov]

@dengert I developed and tested #728 on opensc-0.16.0 branch
(For a while on local repo. Will be pushed to github after some grace time for discussion of PR. )

PR #728 is not to be merged to master, but rather to be discussed.
(Yes, after reflections, I could make PR relative to opensc-0.16.0.)

RC2 has to be with these changes.

I will finish the QA testing of RC1 for IAS/ECC on WIndows (with code of this PR),
then some, not exhaustives, tests with the other cards that I have,
then wait a little bit for the testing results from other people,
cleanup release notes,
and then merge to master.

[dengert]

@viktorTarasov
I am not doing anything else with OpenSSL-1.1.0 until 0.16.0 is merged to master. I don't expect the OpenSSL-1.1.0 changes to be part of 0.16.0.

Are you planing on #728 being part of 0.16.0?

[viktorTarasov]

@dengert

Are you planing on #728 being part of 0.16.0?

Yes that's my intention. Without it X509 Enrollment for IAS/ECC is not working.

[dengert]

OK.

[germanblanco]

@frankmorgner, thank you for referencing #694.
It does not concern the common part, but what will it take to get it in then?
Will it be enough to get a review from e.g. @rickyepodery and @miguel-cv?
This change removes memory leaks and improves the baseline for the DNIe module in order to make a better use of the OpenSC SM framework in the next release.

[mouse07410]

@viktorTarasov, @frankmorgner, @dengert could you please explain to me the status of OpenSC branches, particularly "master" vs "0.16.0"? I would think that "0.16.0" would be a "frozen" stable off-shoot from "master", but it appears that "0.16.0" has commits not merged into "master" itself...?

So what is the plan? And/or what am I missing?

[dengert]

Good question. I would expect that each RC would be merged into master.

On 4/18/2016 5:39 PM, Mouse wrote:

@viktorTarasov https://github.com/viktorTarasov, @frankmorgner https://github.com/frankmorgner, @dengert https://github.com/dengert could you please explain to me the status of OpenSC branches,
particularly "master" vs "0.16.0"? I would think that "0.16.0" would be a "frozen" stable off-shoot from "master", but it appears that "0.16.0" has commits not merged into "master" itself...?

So what is the plan? And/or what am I missing?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub https://github.com/OpenSC/OpenSC/issues/688#issuecomment-211613225

Douglas E. Engert [email protected]

[viktorTarasov]

For me branch 0.16.0 is the release branch (name may be misleading -- it can be changed), where are fixed the issues that appears during the tests.
This branch contains the RC tags. These tags are proposed for testing. Theses tags are not merged to master. At the end of QA _master_ switched to final RC and tagged as official _0.16.0_ .

There are no frozen branch, there are tags.

During the QA period to _master_ are _cherry-picked_ only fixes of outstanding issues, that are equally present in _prepare-release_ branch.

[dengert]

I don't see the point in in using a branch name, if the intent is to merge it into master when you are done.
I don't see any changes being added to master during this process.
Changes like #739 is a global changes that affect all cards and readers, yet are being added after after 0.16.0 rc1.
Is this change so critical that it needs to be added to RC2?

Do we get more testing done using a RC branch vs adding the changes to master now?

But I am not in a position to do much testing or change the process. Thanks for working on the next release.

On 4/19/2016 3:16 AM, viktorTarasov wrote:

For me branch 0.16.0 is the release branch (name may be misleading -- it can be changed), where are fixed the issues that appears during the tests.
This branch contains the RC tags. These tags are proposed for testing. Theses tags are not merged to master. At the end of QA /master/ switched (or merged) into final RC, this merge will be tagged as
official /0.16.0/ .

There are no frozen branch, there are tags.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub https://github.com/OpenSC/OpenSC/issues/688#issuecomment-211787900

Douglas E. Engert [email protected]

[viktorTarasov]

Is this change so critical that it needs to be added to RC2?

Without #739, to restore init of CardOS, we have to revert 2e21163 .
(Other commits to release branch after rc1 concern the broken MD for IAS/ECC card, absence of control on growing MD log file, ...)

The general problem of current code in the reader-pcsc part is that

• it uses the the reader's TLV property _max-APDU-size_ in a wrong way (ext. APDU reported by PCSC);
• by default all readers supposed to be able for extended APDU which is not the case. Cards, like CardOS, that pretend to support extended APDUs will not work with readers without extended APDU.

Do we get more testing done using a RC branch vs adding the changes to master now?

In _master_ there is no commits that are not present in release branch.

I would like to tag the release branch with _RC2_ after the basic tests with the cards that I have. This tag will be proposed for the final testing.

[frankmorgner]

I think @dengert 's point was that instead of pushing everything to the branch you could push it to master instead. Everything will end up there anyway. A dedicated branch only makes sense if you want to make a feature freeze so that some commits from master will not be included in this release. But since merging has been carefully recently in awareness of the upcoming release there was no such addition to master.

I also agree with @dengert that there were some major additions recently that still need time to be evaluated. I still have in mind the trouble we got last time...

[viktorTarasov]

Everything will end up there anyway.

From this point of view I do not see much subject to debate.

Afais in OpenSC it's rare to have branch dedicated to _fix_ or _feature_. There is no collaborative work -- all _fixex_ and _features_ are in the personal clones.

For me branch dedicated to release is something natural. I do not see substantial importance in different approach. Essential -- tag with official release somewhere in _master_.

[mouse07410]

In master there is no commits that are not present in release branch.

It should be the other way.

I brought the question up because I saw significant divergence between _master_ and _0.16.0_, the latter having 28 more commits (60 files changed, according to GitHub today). If _0.16.0_ is supposed to be a _development_ branch where commits are tried and tested prior to being merged into the master - it's all good and well. If it is a _release_ branch - then the fact that master is way behind the release is troublesome, at least to me.

[viktorTarasov]

In release branch the bugs are found out during the tests, they are fixed and retested in the same, release, branch. So, _release_ branch, in a most natural way, is ahead of _master_.

[mouse07410]

In release branch the bugs are found out during the tests, they are fixed and retested in the same, release, branch...

OK, so it appears what you call "release" I call "development". Because to me it isn't a "release" (not even a "candidate") until it's tested and stable. ;)

Regardless, thanks for your efforts.

0.16.0rc? seems to work with my tokens and PIV cards. Update: not any more (see posts below)

[viktorTarasov]

I call _release_ the branch where the next release is prepared. The head of branch is not stable. Stable are (have to be) the tags.

When it was started I do not thought that there will be serious regression problems. So, by necessity, this branch has _development_ features.

[viktorTarasov]

I changed the name of _release_ branch to _towards-opensc-0.16.0_.

[mouse07410]

:-)

[mouse07410]

I'm sorry to report that the current _towards-opensc-0.16.0_ lost the ability to interact properly with my PIV token via Apple Mail and via OpenSSL-1.0.2g with libp11 (Keychain Access and low-level OpenSC tools still can work with the token to an extent, but e.g., Keychain Access fails to unlock it). Needless to say, it all works fine with OpenSC _master_ branch (screenshots and logs at the very bottom of this post).

In Apple Mail the "Sign" button stays "grayed-out cross" rather than being enabled (and subsequently switching to a check-mark when selected). Here's the /tmp/opensc-debug.log (renamed):
gemalto-0_16_0-bad.txt

With OpenSSL, here's the screen output:

Encrypting this random symmetric key to token RSA KEY MAN key...
$ echo e03a358771937812ba8d1c10c71a57f178a9356752e38cb39705c1c612fe0009 | xxd -r -p -c 200 | openssl rsautl -engine pkcs11 -keyform engine -encrypt -pubin -inkey "pkcs11:object=KEY%20MAN%20pubkey;object-type=public" -pkcs -out /tmp/derive.78971.key.enc
engine "pkcs11" set.
No public keys found.
PKCS11_load_public_key returned NULL
unable to load Public Key

and

Decrypting the symmetric key on the token...
openssl rsautl -engine pkcs11 -keyform engine -decrypt -inkey "pkcs11:object=KEY%20MAN%20key;object-type=private" -pkcs -in /tmp/derive.78971.key.enc | xxd -p -c 200
engine "pkcs11" set.
PKCS#11 token PIN: 
Login failed
login to token failed, returning NULL...
PKCS11_get_private_key returned NULL
cannot load Private Key from engine
140735324196944:error:80005005:Vendor defined:PKCS11_login:General Error:p11_slot.c:216:
140735324196944:error:26096080:engine routines:ENGINE_load_private_key:failed loading private key:eng_pkey.c:124:
unable to load Private Key

and the log (renamed):
gemalto-bad2.txt

And here the correctly working _master_ branch (produced by bash script):

KEY1="6ddc47daf51fe2fd7c62d18c8ed5a5ea787ab2f70d72625e29bc5e987920369a"
Encrypting this random symmetric key to token RSA KEY MAN key...
echo 6ddc47daf51fe2fd7c62d18c8ed5a5ea787ab2f70d72625e29bc5e987920369a | xxd -r -p -c 200 | openssl rsautl -engine pkcs11 -keyform engine -encrypt -pubin -inkey "pkcs11:object=KEY%20MAN%20pubkey;object-type=public" -pkcs -out /tmp/derive.91606.key.enc
engine "pkcs11" set.

Decrypting the symmetric key on the token...
KEY2=`openssl rsautl -engine pkcs11 -keyform engine -decrypt -inkey "pkcs11:object=KEY%20MAN%20key;object-type=private" -pkcs -in /tmp/derive.91606.key.enc | xxd -p -c 200`
engine "pkcs11" set.
PKCS#11 token PIN: 

KEY1="6ddc47daf51fe2fd7c62d18c8ed5a5ea787ab2f70d72625e29bc5e987920369a"
KEY2="6ddc47daf51fe2fd7c62d18c8ed5a5ea787ab2f70d72625e29bc5e987920369a"
Original and decrypted keys  match

and the accompanying log:
gemalto-good.txt

In case you'd like to see a log of a successful Apple Mail interaction (with _master_ branch of course), here it is (token was unlocked before Apple Mail invocation - around line 2566 of the log):
gemalto-mail-good.txt

[viktorTarasov]

@mouse07410
Could you bisect until the problematic commit?

@dengert
In one of the bad log file
after 'transmit failed' on 'get-response' card returns 6D00 in every next APDU. Any idea?

[mouse07410]

It appears that whatever we had around 4 days ago, was working... I'll try to bisect, but... :-(

[dengert]

I don't see the problem with toward-opensc-0.16.0 using OpenSSL-1.0.2 using PIV card.

The good says 0.15.0
The bad says 0.16.rc1

The reader is a Gemalto Prox Dual USB PC Link Reader,
https://pcsclite.alioth.debian.org/ccid/iManufacturer.html#150
This looks like both a contact and contactless reader.

in bad lines 1258, 1267 show Gemalto Prox Dual USB PC Link Reader(2)
00 CB 3F FF 05 5C 03 5F C1 01 08
6D 00

in good lines 1874 1881 Gemalto Prox Dual USB PC Link Reader(2)
00 CB 3F FF 05 5C 03 5F C1 01 08
53 82 03 AF 70 82 03 A6 30 82 03 A2 30 82... 61 FC
it read 254 bytes, even though only 8 bytes were requeseted.
This has worked in the past.

'6D00' is Instruction code not supported or invalid
I don't see and non-card driver code setting 6D 00,
so must be coming from PCSC or CCID reader or the reader.

Note that in both the request is to read only the first 8 bytes,
in bad it get 6D 00
In good it gets more then 8, but this has worked in the past.

Maybe pcsc, CCID or reader can not handle this.

Could the dual reader have switcher the conttach for contaclless?
Could it be using the contactless even though th card is pluged into contact?

Do you have some other reader to try?

Is this some locking problem? Tokend and opensc-pkcs11 twice are accessing the same object
within 12 seconds.

Did we make some change that would assume it could use extended APDU even though the caller did not request it?

On 4/28/2016 2:19 PM, Mouse wrote:

It appears that whatever we had around 4 days ago, was working... I'll try to bisect, but... :-(

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub https://github.com/OpenSC/OpenSC/issues/688#issuecomment-215534117

Douglas E. Engert [email protected]

[mouse07410]

I don't see the problem with toward-opensc-0.16.0 using OpenSSL-1.0.2 using PIV card.

I do. _towards-opensc-0.16.0_ broke at least one reader+card.

The good says 0.15.0. The bad says 0.16.rc1

That's exactly the point. The _master_ branch that still thinks it's 0.15.0, works fine with all the readers I throw at it. The _towards-opensc-0.16.0_ branch does not.

The reader is a Gemalto Prox Dual USB PC Link Reader, ... This looks like both a contact and contactless reader.

Yes it is. And it's listed as fully supported. And it works out of box with the current _master_ branch, both contact and contactless interfaces. Though contactless doesn't work with CAC - but we've been through that, and you explained why that is so. It's not the case of "this is a bad/unsupported reader" (unlike SCL7311 :-) ).

Maybe pcsc, CCID or reader can not handle this

Unlikely - since these stay the same between _master_ and _towards-0.16.0_ installation switches. So the root cause must be something that _towards-0.16.0_ does (differently from _master_) with one or more of the three components above.

Could the dual reader have switcher the contact for contactless?

I don't think so. I noticed no indication of such confusion in the logs, and the indicator LEDs on the reader clearly showed that it stayed in the correct mode throughout.

Could it be using the contactless even though the card is pluged into contact?

Absolutely not.

Do you have some other reader to try?

My goal is to get _this_ reader to work (with the card types I need to use with it), rather than find some reader that would work with some card with this branch. ;)

I can get another contact reader that should absolutely work (limited to CAC cards in PIV mode), and a contactless reader that was proven not to work before. I can use a CAC/PIV card in the contact slot of this reader. Or I can use Yubikey that is its own "USB reader". What do you want me to try, and what do we hope to learn from those experiments?

Is this some locking problem? Tokend and opensc-pkcs11 twice are accessing the same object
within 12 seconds.

Unfortunately I've no idea. My only clue here is that somehow it has been working through all the commits on the _master_ branch of OpenSC.

Did we make some change that would assume it could use extended APDU even though the caller did not request it?

It would be great if we could try to back that change off and check...

[LudovicRousseau]

@mouse07410, as @viktorTarasov already wrote before, the best you can do is to use git bisect to find the problematic git patch.

It you have never used git bisect before you can find a lot documentation on the web like https://git-scm.com/docs/git-bisect.

[dengert]

In gemalto-bad2.txt lines 1101, 2949 and 5145 all have

SCardTransmit/Control failed: 0x7fb880100016

This looks like a malformed debug message, and the return code may actually be
0x80100016 SCARD_E_NOT_TRANSACTED
An attempt was made to end a non-existent transaction.

These failures are not present on the good trace. It looks like the failure causes the card to be detected again,
and after that the next request to read an object gets the 6D00.

line 1095:
0x7fff7f019000 12:29:50.528 [tokend] apdu.c:376:sc_single_transmit: CLA:0, INS:CB, P1:3F, P2:FF, data(5) 0x7fff5cf68778
0x7fff7f019000 12:29:50.528 [tokend] reader-pcsc.c:269:pcsc_transmit: reader 'Gemalto Prox Dual USB PC Link Reader(2)'
0x7fff7f019000 12:29:50.528 [tokend] reader-pcsc.c:270:pcsc_transmit:
Outgoing APDU (11 bytes):
00 CB 3F FF 05 5C 03 5F C1 05 08 ..?..._...
0x7fff7f019000 12:29:50.528 [tokend] reader-pcsc.c:199:pcsc_internal_transmit: called
0x7fff7f019000 12:29:50.564 [tokend] reader-pcsc.c:228:pcsc_internal_transmit: Gemalto Prox Dual USB PC Link Reader(2):SCardTransmit/Control failed: 0x7fc680100016
0x7fff7f019000 12:29:50.564 [tokend] reader-pcsc.c:397:pcsc_detect_card_presence: called

Then in 1153:
0x7fff7f019000 12:29:50.566 [tokend] apdu.c:376:sc_single_transmit: CLA:0, INS:CB, P1:3F, P2:FF, data(5) 0x7fff5cf68778
0x7fff7f019000 12:29:50.566 [tokend] reader-pcsc.c:269:pcsc_transmit: reader 'Gemalto Prox Dual USB PC Link Reader(2)'
0x7fff7f019000 12:29:50.566 [tokend] reader-pcsc.c:270:pcsc_transmit:
Outgoing APDU (11 bytes):
00 CB 3F FF 05 5C 03 5F C1 0A 08 ..?..._...
0x7fff7f019000 12:29:50.566 [tokend] reader-pcsc.c:199:pcsc_internal_transmit: called
0x7fff7f019000 12:29:50.575 [tokend] reader-pcsc.c:279:pcsc_transmit:
Incoming APDU (2 bytes):
6D 00 m.
0x7fff7f019000 12:29:50.575 [tokend] apdu.c:386:sc_single_transmit: returning with: 0 (Success)
0x7fff7f019000 12:29:50.575 [tokend] apdu.c:539:sc_transmit: returning with: 0 (Success)
0x7fff7f019000 12:29:50.575 [tokend] card.c:434:sc_unlock: called
0x7fff7f019000 12:29:50.575 [tokend] card-piv.c:503:piv_general_io: DEE r=0 apdu.resplen=0 sw1=6d sw2=00

Later in a sequence starting at line 2847 to read an object, the first 8 bytes are read,
then at 2826 the command to read in the full object for length 995 is started
The command returns the first 252 bytes + 61 FC
get response at line 2916 requests the next 252 bytes
and the response has 252 bytes + 61 FC

Then at lines 2947 the second get response failures in the middle of reading a certificate object,
Outgoing APDU (5 bytes):
00 C0 00 00 FC .....
0x7fff7f019000 12:29:53.947 [opensc-pkcs11] reader-pcsc.c:199:pcsc_internal_transmit: called
0x7fff7f019000 12:29:53.983 [opensc-pkcs11] reader-pcsc.c:228:pcsc_internal_transmit: Gemalto Prox Dual USB PC Link Reader(2):SCardTransmit/Control failed: 0x7fb880100016
0x7fff7f019000 12:29:53.983 [opensc-pkcs11] reader-pcsc.c:397:pcsc_detect_card_presence: called

The failures appear to be random. Possible issues:

This could be some locking problem is allowing some other process to access the card

There is some timeout issue.

Some memory is being overwritten.
Some change dealing with card vs reader max_send_size and max_recv_size?

If possible, can you get a pcscd trace?
This could show if other processes are interfering.

What also does not make sense, but is in both good and bad traces, only 252 bytes of data are being returned, I would have expected 256
bytes + SW which is what I see on Linux, where the SW is 61 00 rather then 61 FC

http://support.gemalto.com/index.php?id=prox-du_prox-su#.VySvmfkrJhE

The reader appears to be called "IDBridge CL300, IDBridge CL3000 (legacy name: Prox-DU and Prox-SU)"
There is a section on Mac OS drivers.

Douglas E. Engert [email protected]

[dengert]

Also check the opensc.conf being used by both the good 0.15.0 and bad 1.16.0rc1
especially if you have overridden any of the defaults.
There are a number of changes to opensc.conf with 0.16.0.

look at reader_driver pcsc section for the actions taken for each of the SCard* entries.

See what version of libpcsclite.so is being used with each.

On 4/29/2016 2:24 AM, Ludovic Rousseau wrote:

@mouse07410 https://github.com/mouse07410, as @viktorTarasov https://github.com/viktorTarasov already wrote before, the best you can do is to use |git bisect| to find the problematic git patch.

It you have never used |git bisect| before you can find a lot documentation on the web like https://git-scm.com/docs/git-bisect.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub https://github.com/OpenSC/OpenSC/issues/688#issuecomment-215646267

Douglas E. Engert [email protected]

[mouse07410]

Also check the opensc.conf being used by both the good 0.15.0 and bad 1.16.0rc1
especially if you have overridden any of the defaults. There are a number of changes to opensc.conf with 0.16.0.

I stopped changing opensc.conf quite a while ago (except for enabling debug), as the default version(s) seemed to work fine.

See what version of libpcsclite.so is being used with each.

Not sure if I understand - my system probably has only one libpcsclite.so installed?

http://support.gemalto.com/index.php?id=prox-du_prox-su#.VySvmfkrJhE
The reader appears to be called "IDBridge CL300, IDBridge CL3000 (legacy name: Prox-DU and Prox-SU)". There is a section on Mac OS drivers.

This is what that reference says:

Since Mac OS X Yosemite 10.10, no need to install this package as Apple includes a 
recent version natively. This package comes from the libccid project available at
 http://pcsclite.alioth.debian.org/ccid.html

If possible, can you get a pcscd trace? This could show if other processes are interfering.

I'd love to. What's the best way to get it on El Capitan (10.11.4)?

I've never used bisect before. Will study the docs, and try it. But frankly, not extremely optimistic.

[dengert]

"I'd love to. What's the best way to get it (pcscd trace) on El Capitan (10.11.4)?" @LudovicRousseau

Don't know. Have not touched a Mac in years. Apply has not been very friendly towards smart cards:

http://ludovicrousseau.blogspot.com/2015/10/os-x-el-capitan-and-smart-cards-status.html
http://ludovicrousseau.blogspot.com/2014/11/os-x-yosemite-and-smart-cards-status.html

[LudovicRousseau]

You can get the APDU values easily using "Debug a smart card application on Yosemite " http://ludovicrousseau.blogspot.fr/2015/02/debug-smart-card-application-on-yosemite.html

Having access to all the PC/SC calls is not (yet) possible:
"PCSC framework spy: broken since Mac OS X Yosemite" http://ludovicrousseau.blogspot.fr/2016/02/pcsc-framework-spy-broken-since-mac-os.html

[dengert]

In bad line 1101:
0x7fff7f019000 12:29:50.564 [tokend] reader-pcsc.c:228:pcsc_internal_transmit: Gemalto Prox Dual USB PC Link Reader(2):SCardTransmit/Control failed: 0x7fc680100016
0x7fff7f019000 12:29:50.564 [tokend] reader-pcsc.c:397:pcsc_detect_card_presence: called
0x7fff7f019000 12:29:50.564 [tokend] reader-pcsc.c:303:refresh_attributes: Gemalto Prox Dual USB PC Link Reader(2) check
0x7fff7f019000 12:29:50.565 [tokend] reader-pcsc.c:323:refresh_attributes: returning with: 0 (Success)
0x7fff7f019000 12:29:50.565 [tokend] reader-pcsc.c:402:pcsc_detect_card_presence: returning with: 5

The return of says:
SC_READER_CARD_PRESENT 0x00000001
SC_READER_CARD_INUSE 0x00000004

Why is it in use? Is it because the current process has it in use?

reader-pcsc.c has:
232 default:
233 /* Translate strange errors from card removal to a proper return code */
234 pcsc_detect_card_presence(reader);
235 if (!(pcsc_detect_card_presence(reader) & SC_READER_CARD_PRESENT))
236 return SC_ERROR_CARD_REMOVED;
237 return SC_ERROR_TRANSMIT_FAILED;

What does it call pcsc_detect_card_presence twice? (may not be an issue.)

Why does SCardTransmit return:
0x80100016 SCARD_E_NOT_TRANSACTED

Once this occurs, the code does not retry or recover from the error and following commands return 6D 00. If the card is in use by some other process, and the PIV AID is not selected any more, this could
explain why it gets 6D 00.

[mouse07410]

I started git bisect. So far success at:

$ git bisect good
Bisecting: 5 revisions left to test after this (roughly 3 steps)
[5be51ea3e20a05d8604db9f59f7788b87a82018e] pkcs15init: authentIC: init card/pin not supported 
$ git status
HEAD detached at 5be51ea
You are currently bisecting, started from branch 'towards-opensc-0.16.0'.
  (use "git bisect reset" to get back to the original branch)

Will check more tomorrow.

[frankmorgner]

You've lost me. Please move the PIV part into a separate issue.

As far as I understood

• PIV does not seem to work anymore with 0.16.0
• some files need to be finalized https://github.com/OpenSC/OpenSC/issues/688#issuecomment-199952808
• some cards and middleware was tested by @viktorTarasov https://github.com/OpenSC/OpenSC/issues/688#issuecomment-199952808

What about @CardContact and @FeitianSmartcardReader , did you test your cards with the new release?

[dengert]

http://forum.yubico.com/viewtopic.php?f=26&t=2049A
https://militarycac.com/elcapitan.htm

On 5/3/2016 4:38 AM, Frank Morgner wrote:

You've lost me. Please move the PIV part into a separate issue.

As far as I understood

• PIV does not seem to work anymore with 0.16.0

From the debug log sent by https://github.com/mouse07410, the failure occurs when SCardTransmit receives a 80100016
at random times. At one time it was trying to read an object, and the initial APDU of the sequence did not start.
Another time it was in the process read reading chunks of a certificate and the second getresponce APDU failed.
Thus I think it is a MacOS 10.11 install problem or interference of some other PIV aware middleware is accessing
the card and causing it to get reset causing interference.

I don't know what other cards (accept maybe Yubico's PIV) https://github.com/mouse07410 has tested with.

These sites report problems with update caused by MacOS 10.11 SIP causing problems with installs for NEO, PIV and CAC:

http://forum.yubico.com/viewtopic.php?f=26&t=2049A
https://militarycac.com/elcapitan.htm
http://www.mac-forums.com/os-x-operating-system/328044-common-access-card-login-support-lost-el-capitan.html

https://github.com/mouse07410, are you running any other PIV or CAC aware card driver software, like
http://www.thursby.com/products/pkard-mac on the same machine?

• some files need to be finalized #688 (comment) https://github.com/OpenSC/OpenSC/issues/688#issuecomment-199952808
• some cards and middleware was tested by @viktorTarasov https://github.com/viktorTarasov #688 (comment) https://github.com/OpenSC/OpenSC/issues/688#issuecomment-199952808

What about @CardContact https://github.com/CardContact and @FeitianSmartcardReader https://github.com/FeitianSmartcardReader , did you test your cards with the new release?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub https://github.com/OpenSC/OpenSC/issues/688#issuecomment-216480681

Douglas E. Engert [email protected]

[dengert]

To all developers. Has anyone tested the latest 0.16.0 on MacOS?
What version of MacOS? what cards?
Have you used tokend?

@mouse07410
You said you get the failure with other readers. Can you send a debug trace using one of the other readers? I know you want to get the dual reader working, but it is not clear to me at least that the problem exists on other readers.

The https://github.com/OpenSC/OpenSC/pull/739 is looking suspicious, in that it is asking the CCID driver to provide additional information. Apple is now providing PCSC and the CCID driver, and there may be problem in what it returns, or how OpenSC asks the CCID driver to do additional functionality that it was not asked to do before https://github.com/OpenSC/OpenSC/pull/739

i.e. the problem is not so much in OpenSC, but in the Mac CCID driver.

This could be an endian issue, What processor is your MacOS running on?

[mouse07410]

Per @frankmorgner request, moved this discussion to https://github.com/OpenSC/OpenSC/issues/751, where I answered all of the above questions, and provided the logs (some old, and some newly-created).

Here I can only say that the current _towards-0.16.0_ branch completely broke PIV cards on Mac OS X on all the readers I have, which are SCM SCR 3310, Gemalto Prox DU, and NEO standalone.

Update

c63ba858e32950b975bc6817c4dd9276ceea8715 is the first bad commit
commit c63ba858e32950b975bc6817c4dd9276ceea8715
Author: Andreas Schwier <[email protected]>
Date:   Mon Apr 18 14:07:43 2016 +0200

    Detect premature end hexstring

:040000 040000 d6b6a07d2fe702c688c6c2248442eec197c9b17d a84bcb053d1702323f3e31e2992272ab627290ca M  src

[frankmorgner]

CardOS 4.3 works on Mac OS X 10.10 in tokend (client authentication in Safari) with CCID reader (uTrust 4700 F).

[CardContact]

Regression test with SmartCard-HSM V2.1. No errors.

[mouse07410]

This patch makes everything working with PIV on OSX 10.11.4:

diff --git a/src/libopensc/sc.c b/src/libopensc/sc.c
index b378d55..4bdafe8 100644
--- a/src/libopensc/sc.c
+++ b/src/libopensc/sc.c
@@ -77,10 +77,12 @@ int sc_hex_to_bin(const char *in, u8 *out, size_t *outlen)
                        byte |= c;
                }
                // Detect premature end of string before byte is complete
+#if 0
                if (!*in && nybbles >= 0) {
                        err = SC_ERROR_INVALID_ARGUMENTS;
                        break;
                }
+#endif
                if (*in == ':' || *in == ' ')
                        in++;
                if (left <= 0) {

[mouse07410]

Here's what my current working src/libopensc/sc.c looks like. Please notice the move of ENABLE_OPENSSL define one line down!

diff --git a/src/libopensc/sc.c b/src/libopensc/sc.c
index b378d55..cc27d49 100644
--- a/src/libopensc/sc.c
+++ b/src/libopensc/sc.c
@@ -50,10 +50,11 @@ const char *sc_get_version(void)
 int sc_hex_to_bin(const char *in, u8 *out, size_t *outlen)
 {
        int err = SC_SUCCESS;
-       size_t left, count = 0;
+       size_t left = 0, count = 0, in_len = 0;

        assert(in != NULL && out != NULL && outlen != NULL);
        left = *outlen;
+       in_len = strlen(in);

        while (*in != '\0') {
                int byte = 0, nybbles = 2;
@@ -76,11 +77,14 @@ int sc_hex_to_bin(const char *in, u8 *out, size_t *outlen)
                        }
                        byte |= c;
                }
+
                // Detect premature end of string before byte is complete
-               if (!*in && nybbles >= 0) {
+               if (in_len > 1 && *in == '\0' && nybbles >= 0) {
+                       fprintf(stderr, "sc_hex_to_bin(): premature end of string in_len=%1d nybbles=%1d\n", in_len, nybbles);
                        err = SC_ERROR_INVALID_ARGUMENTS;
                        break;
                }
+
                if (*in == ':' || *in == ' ')
                        in++;
                if (left <= 0) {
@@ -829,9 +833,9 @@ void *sc_mem_alloc_secure(sc_context_t *ctx, size_t len)

 void sc_mem_clear(void *ptr, size_t len)
 {
-#ifdef ENABLE_OPENSSL
        /* FIXME: Bug in 1.0.0-beta series crashes with 0 length */
        if (len > 0)
+#ifdef ENABLE_OPENSSL
                OPENSSL_cleanse(ptr, len);
 #else
                memset(ptr, 0, len);

[viktorTarasov]

_OpenSC-0.16.0-rc2_ released.

If no objections, I will use this version to release official _OpenSC-0.16.0_,
at last.

[mouse07410]

No objection. But please take a look at this misplaced #ifdef in src/libopensc/sc.c:

@@ -829,9 +833,9 @@ void *sc_mem_alloc_secure(sc_context_t *ctx, size_t len)

 void sc_mem_clear(void *ptr, size_t len)
 {
-#ifdef ENABLE_OPENSSL
        /* FIXME: Bug in 1.0.0-beta series crashes with 0 length */
        if (len > 0)
+#ifdef ENABLE_OPENSSL
                OPENSSL_cleanse(ptr, len);
 #else
                memset(ptr, 0, len);

[frankmorgner]

Just one more thing: We should extend the build scripts for OS X to include manually building OpenSSL, otherwise only a limited set of cards/actions would be supported.

[mouse07410]

...extend the build scripts for OS X to include manually building OpenSSL...

Please reconsider. I fear very much that these scripts would miss the installed OpenSSL and greatly screw up the entire system by building and installing something different (i.e., OpenSSL of a different version/release, and/or in a different configuration).

First, all of the OS X boxes come with OpenSSL pre-installed. It's a dated version OpenSSL 0.9.8zh 14 Jan 2016 (stupid, Apple!) but they do back-port security fixes.

Second - most users who care about OpenSSL install a more recent version themselves. They have no choice because many other packages depend on OpenSSL. Some (like myself) do it via Macports, some - via brew, some build from sources.

How are you going to make sure there is no working installation of OpenSSL (of the version that this particular user needs, for whatever specific reasons that neither you nor I know) somewhere where your script doesn't know to search in? How are you going to determine what configuration parameters to provide to satisfy this specific user needs?

I think it is no good, and very dangerous to try.

Also, going along that line of thinking, you can't just build OpenSSL - it needs libp11 to properly function. These three packages are currently intertwined:

• OpenSSL needs libp11 to access tokens;
• libp11 needs OpenSC and OpenSSL to access tokens and deal with cryptographic material;
• OpenSC needs OpenSSL to perform cryptographic operations.

Summary I think that OS X build scripts need a good nice clean convenient way to specify where exactly the OpenSC-usable OpenSSL is installed, and a clearly documented statement specifying what is the minimal OpenSSL version compatible with the given release of OpenSC, and what OpenSSL options need to be enabled (if any).

[frankmorgner]

Nope, @mouse07410. We don't want to build https://github.com/OpenSC/engine_pkcs11

[mouse07410]

We don't want to build https://github.com/OpenSC/engine_pkcs11

But you do consider building https://github.com/openssl/openssl ?! I already expressed what I think of this idea (not good!).

Just make it easy to configure the locations of libcrypto.dylib and openssl/*.h. Preferably in one place. Ideally - in a way common to OS X and Unix/Linux. It would already be better than what exists now - with the following to ponder:

MacOSX/Makefile.in:207:OPENSSL_CFLAGS = @OPENSSL_CFLAGS@
MacOSX/Makefile.in:208:OPENSSL_LIBS = @OPENSSL_LIBS@
MacOSX/Makefile.in:211:OPTIONAL_OPENSSL_CFLAGS = @OPTIONAL_OPENSSL_CFLAGS@
MacOSX/Makefile.in:212:OPTIONAL_OPENSSL_LIBS = @OPTIONAL_OPENSSL_LIBS@
. . . . .
configure.ac:540:   OPENSSL_CFLAGS=""
configure.ac:541:   OPENSSL_LIBS=""
configure.ac:691:   OPTIONAL_OPENSSL_CFLAGS="${OPENSSL_CFLAGS}"
configure.ac:692:   OPTIONAL_OPENSSL_LIBS="${OPENSSL_LIBS}"
configure.ac:749:AC_SUBST([OPTIONAL_OPENSSL_CFLAGS])
configure.ac:750:AC_SUBST([OPTIONAL_OPENSSL_LIBS])
configure.ac:765:AM_CONDITIONAL([ENABLE_OPENSSL], [test "${enable_openssl}" = "yes"])
configure.ac:877:OPENSSL_CFLAGS:          ${OPENSSL_CFLAGS}
configure.ac:878:OPENSSL_LIBS:            ${OPENSSL_LIBS}
. . . . .

[frankmorgner]

See https://github.com/frankmorgner/OpenSC/commit/673251ad2a8594fe4f7bd06a343c8b82cd4e25db (untested)

[dengert]

Note engine_pkcs11 is now built into libp11.

"The engine_pkcs11 library has been merged into https://github.com/OpenSC/libp11 version 0.4.0 and later. For the time being, this repository is left intact to retain the history of changes before
made prior to the merge."

On 5/17/2016 12:02 PM, Frank Morgner wrote:

Nope, @mouse07410 https://github.com/mouse07410. We don't want to build https://github.com/OpenSC/engine_pkcs11

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub https://github.com/OpenSC/OpenSC/issues/688#issuecomment-219784335

Douglas E. Engert [email protected]

[mouse07410]

Let me say again: extremely bad and dangerous idea. I for one don't want a third version of OpenSSL built and installed on my OS X machine, more likely than not with configuration different fro both Apple pre-built and my specific. It is enough that I have to contend with the pre-built 0.9.8zh and my current 1.0.2h that's used by all the apps that I install.

Not to mention that most people do (and should) use now 64-bit libraries, so your explicit building of openssl_32 looks weird. Not to mention that many people prefer released code to "github-stable" drops.

Not to mention that your build is likely to screw up applications such as OpenSSH, which rely upon a specific OpenSSL installation that was present when it was built.

@frankmorgner If you're so keen of improving scripts - why don't you fix the location of opensc-pkcs11.dylib in generated config.h and resolve https://github.com/OpenSC/OpenSC/issues/741? Instead of adding a useless build that is likely to interfere badly with existing installation, and that any user who cares to compile form the sources, can manage without your help

[frankmorgner]

@mouse07410 it's not installed. It is linked in statically

[mouse07410]

it's not installed. It is linked in statically

Somewhat better - but still, it sucks disk space and adds unnecessary complexity. I for one want my apps to use one OpenSSL - and I want it to be the one whose configuration (and version) I chose. I do not want somebody to stick 1.0.2-stable on my system. Not to mention a likely nice conflict when I get libp11 involved and use OpenSSL (_my_ OpenSSL) to programmatically access tokens, which uses OpenSC that with your help would have a different idea of instances, formats, etc. Not to mention that some of my builds are on disconnected machines...

Why can't you use the installed OpenSSL like the _master_, 0.15.0, and 0.16.0 are doing quite well? You want to prove that you can build OpenSSL via script?

[frankmorgner]

It's simply impractical. There are too many possible locations. Even Apple still ships a deprecated version of OpenSSL (without advertising it).

With all those disk sucking magic tools that apple ships with OS X, I doubt that apple users care for some kilobytes more or less.

[mouse07410]

It's simply impractical.

What "it"? Impractical to locate? Or impractical to document that users who want to use OpenSC must install a more-or-less recent version of OpenSSL, say 1.0.2g+ if they want to use libp11 and OpenSC, or 1.0.1+ if they want to use OpenSC?

I say - just document this requirement, and be done with it. Simple, effective, and non-invasive.

There are too many possible locations.

Fine - so let the user specify two directories, one for libcrypto.dylib and one for the *.h files. What seems to be the problem? _Which somehow appears non-existent on my machines..._

Even Apple still ships a deprecated version of OpenSSL (without advertising it).

So?

With all those disk sucking magic tools that apple ships with OS X, I doubt that apple users care for some kilobytes more or less.

And you're dead wrong here - I for one worry about every extra kilobyte (laptops, and unable to put 1TB drive to alleviate disk space concerns). Especially so because I must install OS updates, which - as you pointed out - already suck a lot of disk space.

[frankmorgner]

And by the way, it's not just impractical. It's also improbable to find OpenSSL, because most users don't have OpenSSL installed via ports.

[mouse07410]

Some install from the source. Some - via Macports. Some - via brew. Some - via Fink. Regardless, unless they stick to the Apple-provided apps, they are likely to use some kind of package management software, and among the stuff they installed, at least one package that needs OpenSSL is bound to occur. Which means - they'd have OpenSSL installed anyway.

If you think a user is capable of building OpenSC from the source, why wouldn't that same user be able to install OpenSSL in the very same way?

It's also improbable to find OpenSSL, because most users don't have OpenSSL installed via ports.

So let the user tell you where the relevant files are. Why is this so difficult???

[frankmorgner]

this kind of detection at compile time is still possible. However, you can't expect users to have OpenSSL installed when creating binaries for distribution (i.e. the dmg everyone downloads). And this is actually what the script in question is intended to build. If you want to do something special then you're encouraged to tweak every step of the build process to your needs.

[mouse07410]

However, you can't expect users to have OpenSSL installed when creating binaries for distribution (i.e. the dmg everyone downloads).

Well, I can - but I agree that the locations (and possibly versions) could be different from what the "customers" have.

If you want to do something special then you're encouraged to tweak every step of the build process to your needs.

I would much rather have a script that is easy to tweak, preferably in as small a number of places as possible. So for example, if your OpenSSL build block could just be commented out and replaced by

OPENSSL_CFLAGS=-I/opt/local/whatever -maes -mwhatever
OPENSSL_LIBS=-L/opt/local/wherever -lcrypto

I'd be happy enough. I don't want to interfere with what distribution builders need to do - but I don't want their process to make my simple re-build from the source a torture.

[frankmorgner]

@mouse07410 see #764 for the OS X problems discussed

[mouse07410]

@mouse07410 see #764 for the OS X problems discussed

I see no discussion there, just a PR that you say you validated on OS X. I cannot validate it, because my setup does not allow for pulling other versions of OpenSSL even if I wanted to (which I don't).

Again, as I do not produce DMGs for others, I don't feel I have a voice in the discussion about how the developers/maintainers should do the build.

My only need and hope is that _my_ builds would still work, i.e., without bringing a different OpenSSL version to _my_ machines. So as long as I can easily edit the script, commenting out the part that pulls and builds OpenSSL and specifying where _my_ OpenSSL lives (without negative consequences to the rest of the build, like hidden dependencies and what not) - I cannot object.

Please make sure environmental variables OPENSSL_CFLAGS and OPENSSL_LIBS are respected throughout the build, and nothing else is needed to locate and access OpenSSL include files and libraries by the build process.

[viktorTarasov]

So, what is the conclusion?

I have nothing to say about MacOS.
Afais, @frankmorgner and @pyther are for integrating the #764 to release,
and @mouse07410 is not categorically against.

What shall we do?

[frankmorgner]

So no objections :wink:; then I'll merge the PR. I'll also cherry-pick https://github.com/OpenSC/OpenSC/pull/763

[frankmorgner]

There is also https://github.com/OpenSC/OpenSC/pull/759, which should be integrated into the release

[viktorTarasov]

Yes, I'm looking on it. I will cherry-pick it.

[viktorTarasov]

@frankmorgner I will wait for your merge and then will push few cherry-picked evident PRs.

[viktorTarasov]

And it has to be a version that is ready to be tagged as official _0.16.0_.

[frankmorgner]

@viktorTarasov done

[viktorTarasov]

@frankmorgner fine, thanks.

[mouse07410]

I've tested the current Github version of towards-0.16.0, and it passed all my tests. I had to make one change though:

diff --git a/MacOSX/build-package.in b/MacOSX/build-package.in
index 55b15fe..e0365ea 100755
--- a/MacOSX/build-package.in
+++ b/MacOSX/build-package.in
@@ -19,7 +19,7 @@ export CFLAGS="$CFLAGS -isysroot $SDK_PATH -arch x86_64 -mmacosx-version-min=10.

 export SED=/usr/bin/sed
 PREFIX=/Library/OpenSC
-export PKG_CONFIG_PATH=/usr/lib/pkgconfig
+export PKG_CONFIG_PATH=/opt/local/lib/pkgconfig

 if ! pkg-config libcrypto --atleast-version=1.0.1; then
        # OpenSSL is not installed

The reason is obvious: it is well-known that Apple's version of OpenSSL is beneath contempt, so it's pretty much pointless to confirm that it's there and that it's old.

What I need is for OpenSC to find the version that _I installed_. Which happens to live in /opt/local (which, BTW, is the only location of pkg-config binary - it looks like OSX does not include it).

Please don't mess with this env variable at all: if the system has pkg-config, it must know its default path; and if the system does not have pkg-config, then what's the point...

[lbevilacqua]

Hello there,
I built the Mac flavor of towards-0.16.0 and I noticed one thing: is it normal/known that Keychain Access doesn't display anymore the certificates inside my italian CNS-like cards (but can lock and unlock them)?
I tried to login on some website with the card (eg. university, public administration services, etc) and Safari can "see" the certificates inside the card (and Firefox too using opensc-pkcs11.so)...

[mouse07410]

Showstopper Fixed by 9d88ae3

Doing regression testing on my old scripts, I found that pkcs11-tool no longer can derive EC keys. See https://github.com/OpenSC/OpenSC/issues/771

[mouse07410]

@lbevilacqua you may need a working tokend.

[lbevilacqua]

@mouse07410 Thank you for pointing that out, I guess the government-provided software messed with the OpenSC installation. Installing RC2 on a clean system reconized 3 different cards without any issue.

[viktorTarasov]

OpenSC 0.16.0 is created, thank you for your time and your efforts.

[frankmorgner]

I also attached an image for OS X 10.10 and later

[viktorTarasov]

Fine, I pushed the image to souceforge.

[CardContact]

Thanks Viktor and all the other contributors for making this release happen.

Andreas

On 06/03/2016 02:45 PM, viktorTarasov wrote:

OpenSC 0.16.0 is created, thank you for your time and your efforts.

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSC/OpenSC/issues/688#issuecomment-223569038

---------    CardContact Systems GmbH

|.##> <##.| Schülerweg 38
|# #| D-32429 Minden, Germany
|# #| Phone [phone]
|'##> <##'| http://www.cardcontact.de
--------- Registergericht Bad Oeynhausen HRB 14880
Geschäftsführer Andreas Schwier