Thank you Max for the review.
This seems to be true that the actual provider may be selected when
Signature.init() is called. At least, I see that
Signature.engineInitSign() may call chooseProvider() method.
http://hg.openjdk.java.net/jdk9/dev/jdk/file/a54e33fc0f2d/src/java.base/share/classes
On 03/09/2017 09:55 AM, Artem Smotrakov wrote:
Hi Max,
I am not sure if SunMSCAPI has higher priority than SunJCE, SUN, etc on
Windows. But this test is for SunMSCAPI provider, so we explicitly set
this provider for Signature.
OK. You fix is good then.
What I was saying that even if SunMSCA
Hi Max,
I am not sure if SunMSCAPI has higher priority than SunJCE, SUN, etc on
Windows. But this test is for SunMSCAPI provider, so we explicitly set
this provider for Signature.
Artem
On 03/08/2017 04:50 PM, Weijun Wang wrote:
I remember Signature is able to automatically switch to the co
I remember Signature is able to automatically switch to the correct
provider when its init(key) is called. Does this mean you don't need to
care about Signature.getInstance(alg,provider)?
Thanks
Max
On 03/09/2017 05:52 AM, Artem Smotrakov wrote:
Hello,
The test fails with "Key type not suppo
Since Sean and you are asking similar questions, I'll answer it here.
It was to be consistent with by using the Debug class. If a change is
made to Debug to print elsewhere, what I have now is compatible.
Sending it to stderr is basically saying that Debug is a useless class
and we should just
Hello,
The test fails with "Key type not supported" error on Windows only with
SunMSCAPI provider. It happens because the test passes an incompatible
key object to Signature instance. Please see more details in
https://bugs.openjdk.java.net/browse/JDK-8176183?focusedCommentId=14058876&page=co
- DisabledAlgorithmConstraints.java
You can just call Thread.dumpStack (which dumps to stderr) here if debug
is set. OTOH, I am concerned this will quickly fill up the log file with
stack traces (which can be long). Do we really need this?
--Sean
On 3/8/17 4:15 PM, Anthony Scarpino wrote:
H
Looks fine to me except a minor comment.
In the update of DisabledAlgorithmConstraints.java, the dumping of stack
trace for every checking could increase the debug log size a lot. There
is no verbose option for 'certpath' debug. What do you think if only
dumping the log when the usage is not
Looks fine to me.
Thanks,
Xuelei
On 3/8/2017 1:20 PM, Amanda Jiang wrote:
Hi All,
Could you please help to review the patch below?
sun/security/ssl/X509KeyManager/PreferredKey.java failed on all
platforms since related certificate in keystore has been expired.
To fix the bug, the keystore sho
Hi All,
Could you please help to review the patch below?
sun/security/ssl/X509KeyManager/PreferredKey.java failed on all
platforms since related certificate in keystore has been expired.
To fix the bug, the keystore should be carefully updated with new
certificate since a lot of tests depended
Hi,
I need a code review of this small change.. The PKIX path for usage
checking didn't pass the variant to the checkers because of a previous
needed check for plugins.
http://cr.openjdk.java.net/~ascarpino/8176350/webrev/
thanks
Tony
Would you please review below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8176337
webrev: http://cr.openjdk.java.net/~mli/8176337/webrev.00/
These tests are failing intermittently, they should be marked
accordingly with
@key intermittent
java/nio/channels/FileChannel/Transfer.j
> sun/security/tools/keytool/DefaultSignatureAlgorithm.java
> javax/net/ssl/DTLS/CipherSuite.java
The above two updates look fine to me.
Thanks,
Xuelei
On 3/7/2017 7:36 PM, Hamlin Li wrote:
Would you please review below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8176337
webrev: http
On 08/03/2017 03:36, Hamlin Li wrote:
Would you please review below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8176337
webrev: http://cr.openjdk.java.net/~mli/8176337/webrev.00/
These tests are failing intermittently, they should be marked
accordingly with
@key intermittent
14 matches
Mail list logo
