I looked at the tests and thought about it some more.
I agree that it makes sense to defer the check to post the security check.
Changes look fine.
Thanks,
Valerie
On 7/23/2014 9:51 AM, Valerie Peng wrote:
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.
