RFR : 8051614 : smartcardio TCK tests fail due to lack of 'reset' permission

Valerie Peng valerie.peng at oracle.com
Wed Jul 23 16:51:04 UTC 2014


Do you know which TCK tests fail? I want to check it out.
Thanks,
Valerie

On 7/23/2014 1:15 AM, Seán Coffey wrote:
> Valerie,
>
> I agree it's not ideal, but we're doing nothing different than what 
> was performed in the old JDK releases...(i.e no check there either). I 
> can't say if many applications would be impacted by the 
> Card.disconnect change going into 8u20 but we should make best efforts 
> to preserve the old legacy/buggy behaviour via the new 
> sun.security.smartcardio.invertCardReset system property.
>
> If you disagree, we can launch a challenge against the TCK tests which 
> are failing with this new property flag.
>
> regards,
> Sean.
>
> On 23/07/2014 00:23, Valerie Peng wrote:
>>
>> Well, I see your point.
>> However, I am a little concerned that the security check isn't being 
>> performed in the old buggy impl.
>> Is there any customer running into this, e.g. rely on the old 
>> behavior with security manager enabled?
>> Valerie
>>
>> On 7/22/2014 2:45 PM, Seán Coffey wrote:
>>> A recent fix was introduced to preserve the behaviour of an old 
>>> buggy implementation of smartcardio Card.disconnect :
>>> https://bugs.openjdk.java.net/browse/JDK-8049250
>>>
>>> The old behaviour is not fully restored with this flag if a security 
>>> manager lacking sufficient permissions is present. This could 
>>> disrupt legacy applications which may wish to rely on the old 
>>> behaviour. Some internal testing has also highlighted this.
>>>
>>> To enhance the 8049250 fix, I'm proposing we delay the boolean flip 
>>> operation until post the security check.
>>> http://cr.openjdk.java.net/~coffeys/webrev.8051614/webrev/
>>> Bug report is not public due to internal links and servers being 
>>> present in description.
>>>
>>> I'd like to get this into JDK 9 and 8u20.
>>>
>>> regards,
>>> Sean.
>



More information about the security-dev mailing list