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.
