PING - [jdk9] RFR: 8153438: Avoid repeated "Please insert a smart card" popup windows

[Valerie Peng]

I am not familiar with the general behavior of 
CryptAcquireCertificatePrivateKey API.

Would the first CryptAcquireCertificatePrivateKey(.., 
CRYPT_ACQUIRE_SILENT_FLAG, ...) ever return TRUE?
If yes, then do we need to release the context and call 
CryptAcquireCertificatePrivateKey(..) again?

I'd expect the overall logic to be something like:

    if (::CryptAcquireCertificatePrivateKey(pCertContext,
    CRYPT_ACQUIRE_SILENT_FLAG, NULL,&hCryptProv, &dwKeySpec,
    &bCallerFreeProv) == FALSE) { if (GetLastError() ==
    NTE_SILENT_CONTEXT) { // Try acquiring the key normally (not
    silently)if (::CryptAcquireCertificatePrivateKey(pCertContext, 0,
    NULL, &hCryptProv, &dwKeySpec, &bCallerFreeProv) == FALSE)
    {bHasNoPrivateKey = TRUE;   } } else { bHasNoPrivateKey = TRUE; } }
    // Then proceed on different code paths based on bHasNoPrivateKey value


Anything that I missed?
Valerie

On 8/16/2016 6:27 AM, Vincent Ryan wrote:
> That fix looks fine. Is there any significant performance impact due to calling CryptAcquireCertificatePrivateKey twice?
> Thanks.
>
>> On 16 Aug 2016, at 13:56, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
>>
>> A gentle reminder.
>>
>> Would you please help review at your convenience.
>>
>> With kind regards,
>> Ivan
>>
>>
>> On 09.08.2016 12:27, Ivan Gerasimov wrote:
>>> Hello!
>>>
>>> In order to reduce the number of popup dialog windows during accessing the smartcard, it is proposed to first do a silent "probe" step.
>>> Only if this probe succeeded, or if it failed due to that SILENT flag, we'll try to re-acquire the key normally (i.e. not silently).
>>>
>>> Would you please help review this proposal?
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8153438
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8153438/00/webrev/
>>>
>>> With kind regards,
>>> Ivan
>>>
>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20160816/2439432d/attachment.htm>