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

[Ivan Gerasimov]

Hi Valerie!


On 17.08.2016 1:25, Valerie Peng wrote:
>
> Hmm, interesting...
>
> So, if the first call succeeded and you release the context and 
> re-try. Does the popup window show up for the second call?
> Just curious.
>
I assume that CryptAcquireCertificatePrivateKey() only displays the UI 
when necessary, so if the context could be acquired silently (i.e. the 
result is TRUE), it will be possible to acquire it with no UI and 
without explicit SILENT flag.

With kind regards,
Ivan

> Changes look fine.
> Valerie
> On 8/16/2016 1:06 PM, Ivan Gerasimov wrote:
>>
>> Thank you Valerie for looking into this!
>>
>>
>> On 16.08.2016 22:18, Valerie Peng wrote:
>>>
>>>
>>> I am not familiar with the general behavior of 
>>> CryptAcquireCertificatePrivateKey API.
>>>
>>> Would the first CryptAcquireCertificatePrivateKey(.., 
>>> CRYPT_ACQUIRE_SILENT_FLAG, ...) ever return TRUE?
>>
>> Yes.  It returns TRUE if the key could be acquired silently, and I've 
>> seen this happening.
>>
>>> 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
>>>
>> This was the first thing I attempted to do.
>> However, some subsequent operations with the key started to fail, 
>> throwing SignatureException (with the message "Provider could not 
>> perform the action since the context was acquired as silent.")
>>
>> That's why I switched to what is in this proposal: Silent probing and 
>> then re-acquiring the key normally (not silently).
>>
>> With kind regards,
>> Ivan
>>
>>> 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/20160817/c905f574/attachment.htm>