The fix for JDK-8159752 accidentally put back an older version of the
policy permissions for the jdk.crypto.ucrypto module. It is a simple fix
to restore the correct permission:
diff -r 5584be31a8f9 src/java.base/solaris/lib/security/default.policy
--- a/src/java.base/solaris/lib/security/defau
Hi Valerie,
Can you also clean up the noaccess.policy and access.policy files and
remove the permissions that are now granted to the jdk.crypto.mscapi
module in default.policy?
Also, in the test, I would use the java.security.policy== option instead
of the policy option. The policy option is
os.family == "windows"
--Sean
Mandy
On Aug 3, 2016, at 6:09 AM, Sean Mullan wrote:
Hi Valerie,
Can you also clean up the noaccess.policy and access.policy files and remove
the permissions that are now granted to the jdk.crypto.mscapi module in
default.policy?
Also, in the tes
Looks good.
--Sean
On 08/03/2016 07:15 PM, Valerie Peng wrote:
Sure, webrev updated:
http://cr.openjdk.java.net/~valeriep/8154113/webrev.01/
Thanks,
Valerie
On 8/3/2016 6:09 AM, Sean Mullan wrote:
Hi Valerie,
Can you also clean up the noaccess.policy and access.policy files and
remove the
Looks good to me. You will need to add an appropriate noreg label to the
bug.
--Sean
On 08/08/2016 03:28 AM, Weijun Wang wrote:
Hi All
Please review the code change at
http://cr.openjdk.java.net/~weijun/8163303/webrev.00
I removed the "@SuppressWarnings("deprecation")" at the beginning.
Is there any way to split the Ucrypto MessageDigest implementation into
2 classes, one that implements Cloneable and the other which doesn't,
and use the appropriate one depending on which OS version you are on?
This way, instead of calling clone and catching
CloneNotSupportedException, you co
Or better yet, just change the ucrypto impl to not implement Cloneable
regardless what Solaris version you are on. Then you can just check each
MessageDigest impl to see if it is an instanceof Cloneable rather than
calling clone on each.
--Sean
On 08/09/2016 09:38 AM, Sean Mullan wrote:
Is
- src/java.base/share/classes/sun/security/tools/keytool/Resources.java
131 "operates on the cacerts keystore"}, // -cacerts
"operates" sounds a little odd. How about "access the cacerts keystore"
(so it is consistent with the warning below).
133 "Warning: use
Looks fine to me. Please add a noreg-trivial or noreg-cleanup label to
the bug.
--Sean
On 08/09/2016 02:35 AM, John Jiang wrote:
Hi,
In ProblemList.txt, the tests
sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java and
sun/security/pkcs11/KeyAgreement/UnsupportedDHKeys.java are tracked by
81
Hi Brad,
Looks pretty good. You should also send this to build-dev to review the
Makefile changes. Just a few comments:
- src/java.base/share/conf/security/policy/README.txt
17 contain no restrictions on cryptographic strengths, but they must
s/must/must be/
18 specifically activated by upd
On 08/10/2016 12:39 PM, Vincent Ryan wrote:
Yes they could be merged but the first loop iterates over all the certs and the
second one iterates over all but the final cert.
And the special case of a 1-cert chain also needs to be handled. I think it’s a
little clearer to leave them separate.
A
dated: http://cr.openjdk.java.net/~valeriep/8157579/webrev.02
Looks good.
--Sean
Thanks,
Valerie
On 8/9/2016 10:43 AM, Sean Mullan wrote:
Or better yet, just change the ucrypto impl to not implement Cloneable
regardless what Solaris version you are on. Then you can just check
each MessageDigest
to
the validateChain method.
Updated webrev is at:
http://cr.openjdk.java.net/~vinnie/8163503/webrev.02/
On 10 Aug 2016, at 21:15, Sean Mullan wrote:
On 08/10/2016 12:39 PM, Vincent Ryan wrote:
Yes they could be merged but the first loop iterates over all the certs and the
second one
Please review this simple fix to append the solaris default.policy file
to the overall default.policy file.
Bug: https://bugs.openjdk.java.net/browse/JDK-8164071
diff -r 551f7617b2c0 make/copy/Copy-java.base.gmk
--- a/make/copy/Copy-java.base.gmk Wed Aug 17 10:08:18 2016 +0800
+++ b/make/c
/default.policy
endif
Thanks. However, shouldn't that be "ifeq" and not "ifneq"?
--Sean
/Erik
On 2016-08-17 18:18, Sean Mullan wrote:
Please review this simple fix to append the solaris default.policy
file to the overall default.policy file.
Bug: https://bugs.openjdk.ja
Looks fine to me.
--Sean
On 08/17/2016 04:11 PM, Anthony Scarpino wrote:
Hi,
I need a simple review on fixing some cut-n-paste errors that the JCK
tests found.
I didn't include the tests because the functionality is covered by the
JCK tests and I don't feel typos need a regression test.
http
On 08/17/2016 07:22 PM, Bradford Wetmore wrote:
- src/java.base/share/conf/security/java.security
854 crypto.policy=policydir-tbd
The policydir-tbd value is a little confusing in that it isn't a real
value. What about just setting this to the empty string?
It's a similar marker for the string
Please review this docs-only fix to provide descriptions for the
jdk.security.auth and jdk.security.jgss modules:
diff -r 657a5b92e26e src/jdk.security.auth/share/classes/module-info.java
--- a/src/jdk.security.auth/share/classes/module-info.java Fri Aug 19
13:50:03 2016 +0200
+++ b/src/jdk.sec
Please review this fix to add a new security property that allows you to
configure the individual restrictions that are enabled by the XML
Signature secure validation mode.
bug: https://bugs.openjdk.java.net/browse/JDK-8151893
webrev: http://cr.openjdk.java.net/~mullan/webrevs/8151893/webrev.00
08/24/2016 03:17 PM, Sean Mullan wrote:
Please review this fix to add a new security property that allows you to
configure the individual restrictions that are enabled by the XML
Signature secure validation mode.
bug: https://bugs.openjdk.java.net/browse/JDK-8151893
webrev: http://cr.openjdk.jav
On 08/24/2016 10:25 PM, Xuelei Fan wrote:
On 8/25/2016 7:57 AM, Sean Mullan wrote:
I posted an updated webrev:
http://cr.openjdk.java.net/~mullan/webrevs/8151893/webrev.0
I guess the link should be:
http://cr.openjdk.java.net/~mullan/webrevs/8151893/webrev.01/
Yes, thanks.
--Sean
On 08/25/2016 09:47 AM, Xuelei Fan wrote:
http://cr.openjdk.java.net/~mullan/webrevs/8151893/webrev.01/
Looks fine to me except the following minor comment.
java.security
-
818 # AlgConstraint
819 # "disallowAlg" Uri
...
829 # For AlgConstraint, Uri is the algorithm URI
Real trivial fix, just updating obsolete bug URLs in code comments.
bug: https://bugs.openjdk.java.net/browse/JDK-8150158
$ hg diff --nodates -a -U 1
diff -r 9c7eb3e1799f
src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java
---
https://bugs.openjdk.java.net/browse/JDK-8024714
A trivial fix to remove the quotes from the ocsp property name examples
in the java.security file as they should not be included and will cause
a parsing exception if included:
$ hg diff -U 1 --nodates
diff -r 8c0d4a9bfea1 src/java.base/share/c
On 08/24/2016 08:21 PM, Bradford Wetmore wrote:
Sean Mullan wrote:
> What about setting the default value to "limited"? And then this
> would only be changed to "unlimited" if the build --enable-unlimited-
> crypto option is specified?
I could, but I'm con
Looks fine, but can you change the bug synopsis to something more
specific than "A few typos in javadoc"?
Thanks,
Sean
On 09/04/2016 02:04 AM, Ivan Gerasimov wrote:
Thank you Max for looking at this!
On 04.09.2016 3:37, Weijun Wang wrote:
- * three modulus sizes mentioned above. Still other
Actually, I don't really think this permission target belongs in
RuntimePermission since it is specific to Oracle's Java Plugin. I would
be in favor of removing it and only documenting it in the deployment guides.
--Sean
On 09/08/2016 02:17 PM, Lance Andersen wrote:
all good Joe
On Sep 8, 20
Looks fine to me, but can you explain in more detail why the extra
dependencies are needed, or an example using --limit-modules? These
tests are not failing regularly now, so when do the missing dependencies
cause failures?
Thanks,
Sean
On 09/13/2016 08:34 AM, Sergei Kovalev wrote:
Hello tea
reg header then jtreg suite skip the test and mark it "not
run" in final report. This help me to clean out all "false positive"
error during testing and reduce time that I spend to failures analysis.
14.09.16 18:20, Sean Mullan wrote:
Looks fine to me, but can you explain in mor
The NIST PKITS test suite is a good one and contains a whole bunch of
certificates/CRLs for testing compliance with RFC 3280:
http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html
--Sean
On 09/15/2016 07:19 PM, Milton Smith wrote:
Hi All,
I'm looking for a set of certificates,
The "jrt" URL scheme syntax is new and not widely known yet, so an
example has been added to the conf/security/java.policy file to help
users show how to grant permissions to a module:
http://cr.openjdk.java.net/~mullan/webrevs/8166632/webrev.00/
Thanks,
Sean
On 10/05/2016 10:58 AM, Alan Bateman wrote:
On 05/10/2016 15:57, Sean Mullan wrote:
The "jrt" URL scheme syntax is new and not widely known yet, so an
example has been added to the conf/security/java.policy file to help
users show how to grant permissions to a mod
Looks good to me.
--Sean
On 10/05/2016 04:20 PM, Anthony Scarpino wrote:
Hi,
I'd like a review of this simple fix. There's no test as the fix is
trivial and it's not practical to test a non-existent cacerts file in a
concurrent testing environment
http://cr.openjdk.java.net/~ascarpino/816510
Please review this change to fix a potential array index overflow in the
XML security Base64 encoding class. This is a direct import of the
corresponding patch that has already been made to the Apache code.
webrev: http://cr.openjdk.java.net/~mullan/webrevs/8162723/webrev.00/
Thanks,
Sean
* AlgorithmChecker
Not sure why these changes are necessary or why the check method has
been made non-static. Isn't the previous code sufficient?
* OCSP
129 responderURI, new OCSPResponse.IssuerInfo(null,
issuerCert), null,
Passing null to OCSPResponse.IssuerInfo will throw an
that is the trust anchor, so I would just use
null.
--Sean
On 10/12/2016 07:55 AM, Sean Mullan wrote:
* AlgorithmChecker
Not sure why these changes are necessary or why the check method has
been made non-static. Isn't the previous code sufficient?
Yeah, that change doesn
On 10/12/2016 04:06 PM, Anthony Scarpino wrote:
On 10/12/2016 12:15 PM, Sean Mullan wrote:
On 10/12/2016 01:47 PM, Anthony Scarpino wrote:
New webrev: http://cr.openjdk.java.net/~ascarpino/8165274/webrev.02/
* DisabledAlgorithmConstraints
700 "Algorithm constr
On 10/13/2016 01:29 AM, Anthony Scarpino wrote:
On 10/12/2016 01:41 PM, Sean Mullan wrote:
On 10/12/2016 04:06 PM, Anthony Scarpino wrote:
Later in the verify(), AlgorithmChecker needs a TrustAnchor object. In
this case, because it's the old method that deploy is using, I have to
manufa
Please review this fix to only grant the necessary PropertyPermissions
to the jdk.crypto.ucrypto module.
In UcryptoProvider I also moved the System.getProperty("os.name") inside
doPrivileged (just in case permission to read this property has not been
granted to the caller) and did some minor r
Please review this fix to remove granting the unnecessary
PropertyPermission to the jdk.crypto.ec module:
http://cr.openjdk.java.net/~mullan/webrevs/8168078/webrev.00/
The existing TestEC test has been modified to also run under a
SecurityManager to verify that removing the permission does not
.
Xuelei
On 10/17/2016 10:51 PM, Sean Mullan wrote:
Please review this fix to remove granting the unnecessary
PropertyPermission to the jdk.crypto.ec module:
http://cr.openjdk.java.net/~mullan/webrevs/8168078/webrev.00/
The existing TestEC test has been modified to also run under a
SecurityManager to
Looks good.
--Sean
On 10/19/2016 01:42 PM, Anthony Scarpino wrote:
Hi,
I need a simple review of adding MD5 to the jdk.jar.disabledAlgorithms
security property. It's really a one line change, the comments got
moved to a different location in the file which makes it look bigger.
http://cr.ope
* Main.java
98 private static final DisabledAlgorithmConstraints SIGN_CHECK =
99 new DisabledAlgorithmConstraints(
100
DisabledAlgorithmConstraints.PROPERTY_CERTPATH_DISABLED_ALGS);
This should be changed to PROPERTY_JAR_DISABLED_ALGS now that the fix
for 8167594 is in 9.
Looks good.
> On Oct 19, 2016, at 8:07 PM, Wang Weijun wrote:
>
> Updated at
>
> http://cr.openjdk.java.net/~weijun/8163304/webrev.02/
>
> changes to webrev.01 is at
>
> http://cr.openjdk.java.net/~weijun/8163304/webrev.02/interdiff.patch.html
>
> Thanks
> Max
>
Please review this change to tighten or remove unnecessary permissions
granted to the jdk.crypto.pkcs11 module:
http://cr.openjdk.java.net/~mullan/webrevs/8168313/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8168313
In doing so, I refactored the code a little to not use
sun.security.act
Looks good. Add noreg-self label to the bug.
--Sean
On 10/21/2016 05:37 AM, Ivan Gerasimov wrote:
Hello!
A compilation issue with the regression test was observed due to
ambiguity between two X509ExtendedTrustManager classes.
The fix is to organize the imports.
BUGURL: https://bugs.openjdk.j
Hi Bradley,
Thanks for filing the bug, and coming up with a potential patch for the
issue. The bug has just made its way into our system, so we have not
looked at it in detail yet, but in the meantime I added a link to your
post as a comment. You can see the bug here:
https://bugs.openjdk.jav
Please review this change to tighten or remove unnecessary permissions
granted to the jdk.crypto.ucrypto module:
https://bugs.openjdk.java.net/browse/JDK-8167512
http://cr.openjdk.java.net/~mullan/webrevs/8167512/webrev.00/
Thanks,
Sean
On 10/27/2016 12:28 PM, Vincent Ryan wrote:
Your fix looks fine to me Sean.
On 27 Oct 2016, at 17:09, Sean Mullan wrote:
Please review this change to tighten or remove unnecessary permissions
granted to the jdk.crypto.ucrypto module:
https://bugs.openjdk.java.net/browse/JDK-8167512
http
I'm not sure I like the word "trusted". That is too general and fairly
subjective.
I would say the following: "do not apply to trust anchors or self-signed
certificates".
--Sean
On 10/26/2016 08:37 PM, Xuelei Fan wrote:
New webrev:
http://cr.openjdk.java.net/~xuelei/8168822/webrev.01/
Looks good to me.
--Sean
On 10/28/2016 08:17 PM, Bradford Wetmore wrote:
Egads, good catch. I completely missed this one. I will put in
Objects.requireNonNull throughout.
Cipher.java is the one weird one, null or empty gets the same exception.
Brad
On 10/28/2016 5:13 PM, Xuelei Fan wrote
You should only unset the jdk.jar.disabledAlgorithms property if a
jarfile has been specified.
Also, you are printing the warning message for all usages of the
-printcert option, -ssl, etc, which is not correct.
But I don't really think the warning message is necessary. The docs for
the -pri
* SecureRandom
131 * If this attribute is not set or is "false", this class will instead
132 * synchronize access to each of the methods of the {@code
SecureRandomSpi}
133 * implementation.
Not all of the methods are synchronized - engineGetParameters is not,
for example. I think to avo
Looks fine to me.
--Sean
On 11/7/16 7:00 AM, Xuelei Fan wrote:
Hi,
Please review this test update:
http://cr.openjdk.java.net/~xuelei/8169318/webrev.00/
This update is related to JDK-8169086. From the debug log of
JDK-8169086, it is hard to tell the failure is cause by anti-free-port
iss
There's a bug open to update the Standard Names doc to include SHA-3:
https://bugs.openjdk.java.net/browse/JDK-8004078
The security guides typically get updated a bit later. I don't have an
estimate but it will be done before 9 is released.
Thanks,
Sean
On 10/29/16 11:08 AM, Jurrian Fahner
7;t think it is critical
for 9 - we can do it in 10.
--Sean
Thanks
Max
On 11/4/2016 10:54 PM, Sean Mullan wrote:
* SecureRandom
131 * If this attribute is not set or is "false", this class will
instead
132 * synchronize access to each of the methods of the {@code
SecureRandomSpi}
13
Looks fine to me.
--Sean
On 11/7/16 10:10 PM, Wang Weijun wrote:
Everything looks fine now.
--Max
On Nov 8, 2016, at 11:09 AM, Artem Smotrakov wrote:
Here is final version (I hope)
http://cr.openjdk.java.net/~asmotrak/8168882/webrev.04/
Artem
Looks good, please add an appropriate noreg label (probably
noreg-trivial) to the bug.
--Sean
On 11/10/16 4:55 PM, Anthony Scarpino wrote:
Hi,
I need a one line review to null out the password field in the keystore
load op..
http://cr.openjdk.java.net/~ascarpino/8168861/webrev/
thanks
Tony
Looks good.
--Sean
On 11/14/16 1:45 PM, Anthony Scarpino wrote:
Hi,
I need a review of a one liner to revert the PKIXParameter date argument
back to null, aka current time.
http://cr.openjdk.java.net/~ascarpino/8168931/webrev/
thanks
Tony
Looks fine.
--Sean
On 11/15/16 10:45 PM, Jamil Nimeh wrote:
Good suggestions, thanks.
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8043252/webrev.02
--Jamil
On 11/15/2016 06:18 PM, Wang Weijun wrote:
41 System.setSecurityManager(new SecurityManager());
This is strange. I sup
/interdiff.patch.html
On 11/4/2016 10:54 PM, Sean Mullan wrote:
* SecureRandom
131 * If this attribute is not set or is "false", this class will
instead
132 * synchronize access to each of the methods of the {@code
SecureRandomSpi}
133 * implementation.
Not all of the methods are sy
On 11/20/16 2:57 PM, Bernd Eckenfels wrote:
Hello,
how will the JCE Provider signing in Java 9 work? Are the jmod files
signed (I dont see a signature in them in the Windows EA builds)?
Third party JCE providers still need to be signed as a JAR file.
On the BouncyCastle Crypto mailing list t
Please review this fix for a bug where certificates were not being
blocked if the algorithm is only listed in the
jdk.tls.disabledAlgorithms property and not the
jdk.certpath.disabledAlgorithms property.
I have modified an existing regression test to test this functionality
as there was no pr
On 11/21/16 5:43 PM, Anthony Scarpino wrote:
On 11/21/2016 01:09 PM, Sean Mullan wrote:
Please review this fix for a bug where certificates were not being
blocked if the algorithm is only listed in the
jdk.tls.disabledAlgorithms property and not the
jdk.certpath.disabledAlgorithms property.
I
On 11/27/16 7:43 AM, Xuelei Fan wrote:
On 11/27/2016 6:04 PM, Wang Weijun wrote:
This is not only a test update.
No, I happened to find an implementation issue with the new test, so fix
it altogether. The issue is that the simple validator
(SimpleValidator.java) does not support SKID/AKID dur
/
Thanks,
Sean
On 11/22/16 11:00 AM, Anthony Scarpino wrote:
On 11/22/2016 05:19 AM, Sean Mullan wrote:
On 11/21/16 5:43 PM, Anthony Scarpino wrote:
On 11/21/2016 01:09 PM, Sean Mullan wrote:
Please review this fix for a bug where certificates were not being
blocked if the algorithm is only listed in
On 12/2/16 11:41 AM, Anthony Scarpino wrote:
It looks fine. One question, line 866 of the test you print the stacktrace on a
success, was that intentional?
No, good spot, it is leftover from debugging, I'll remove it before I push.
--Sean
Tony
On Dec 1, 2016, at 11:02 AM, Sean M
Hi John,
I don't think we should modify the test to disable a SecurityManager and
then reenable it to avoid a security check -- that seems like a pattern
we should avoid. Have you tried to reorganize this code so that this
setup is done before you initially enable the SecurityManager?
Thanks
Looks good, but don't forget to add a noreg-self label to the bug.
--Sean
On 12/4/16 9:29 PM, John Jiang wrote:
Hi Sean,
Thanks for your comments.
Please take a look at the new wevrev:
http://cr.openjdk.java.net/~jjiang/8170523/webrev.01/
Best regards,
John Jiang
On 2016/12/3 5:02,
On 12/2/16 2:23 PM, Xue-Lei Fan wrote:
On 11/29/2016 5:22 AM, Sean Mullan wrote:
On 11/27/16 7:43 AM, Xuelei Fan wrote:
On 11/27/2016 6:04 PM, Wang Weijun wrote:
This is not only a test update.
No, I happened to find an implementation issue with the new test, so fix
it altogether. The
On 12/6/16 8:00 PM, Xuelei Fan wrote:
new webrev:
http://cr.openjdk.java.net/~xuelei/8170329/webrev.02/
Looks good.
--Sean
Looks good. Minor comment - update the copyright to include 2016 as the
last year it was updated, ex:
* Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights
reserved.
Send me the updated diffs and I will push it for you.
--Sean
On 12/7/16 9:14 AM, Adam Petcher wrote:
Minor
Looks good to me. Please add a noreg label (noreg-cleanup or
noreg-trivial probably) to the bug.
--Sean
On 12/9/16 10:53 AM, Adam Petcher wrote:
KeychainStore has a couple of @SuppressWarnings("deprecation")
annotations that were required due to references to an overloaded equals
method in Ob
Looks fine to me.
--Sean
On 12/9/16 3:54 PM, Xuelei Fan wrote:
Hi,
Please review this typo issue introduced in JDK-8170329.
$ hg diff test/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java
@Override
-protected boolean isCustomizeClientConnection() {
+protected boolean isC
On 12/8/16 11:17 AM, Adam Petcher wrote:
Subclasses of Signature may have a null provider. In this case, the
debug logging code will throw a NPE when attempting to call getName() on
it. Since this member may be null, I would like to change its type to
Optional to ensure that code checks whether
throws SignatureException {
+return false;
+}
+
+@Deprecated
+protected void engineSetParameter(String param, Object value)
+throws InvalidParameterException {
+// do nothing
+}
+
+@Deprecated
+ protected Object engi
throws InvalidParameterException {
+// do nothing
+}
+
+@Deprecated
+protected Object engineGetParameter(String param)
+throws InvalidParameterException {
+return null;
+ }
+}
+
+public static void main(String[] args) throws Exception {
Hi Max,
Could you include more information that shows what signature algorithm
is used based on the key size range and algorithm?
--Sean
On 12/11/16 9:53 PM, Wang Weijun wrote:
Please take a review at the release note at
https://bugs.openjdk.java.net/browse/JDK-8157389
Thanks
Max
I would check with Jon Gibbons to see if there may be a more "official"
place for exported, non-SE javadocs; otherwise it seems ok to me.
--Sean
On 12/12/16 9:50 PM, Wang Weijun wrote:
Hi All
I've create a new bug to include the javadoc of the non-Java SE JarSigner API
into security doc:
Hi Xuelei,
First cut of a review at this. I still need to review TrustStoreManager,
so will get back to you later on that. Looks very good so far.
* KeyStores.java
Do an 'hg rename' on this file, so you can see the diffs between this
and the new name (TrustStoreUtil), and you preserve the hi
il you post another update
to finish my review.
--Sean
On 12/16/16 11:14 AM, Sean Mullan wrote:
Hi Xuelei,
First cut of a review at this. I still need to review TrustStoreManager,
so will get back to you later on that. Looks very good so far.
* KeyStores.java
Do an 'hg rename' on
I think you missed java.security.KeyPairGenerator which has the same
issue. Otherwise looks good.
--Sean
On 12/15/16 3:08 PM, Adam Petcher wrote:
I'm continuing my quest to rid engine classes of NullPointerException
due to calling getName() on a null provider. This patch fixes Cipher
(which fa
--Sean
On 12/20/2016 4:02 PM, Sean Mullan wrote:
I think you missed java.security.KeyPairGenerator which has the same
issue. Otherwise looks good.
--Sean
On 12/15/16 3:08 PM, Adam Petcher wrote:
I'm continuing my quest to rid engine classes of NullPointerException
due to calling
On 12/20/16 3:21 PM, Xuelei Fan wrote:
213 if (storePassword != null && !storePassword.isEmpty()) {
214 MessageDigest md =
JsseJce.getMessageDigest("SHA-256");
215 result = 31 * result +
216 Arrays.hashCode(md.digest(storePassword.getBytes()));
21
hard to debug. Have you
looked at the AtomicReference class? You could define a new class
containing the descriptor, keystore, and certs and wrap that in an
AtomicReference and then use the methods on that class to update it.
Might be worth exploring that a bit more.
--Sean
On 12/22/2016
-8171190 created and I'll create a
webrev soon.
Thanks
Max
On Dec 14, 2016, at 5:09 AM, Sean Mullan wrote:
Hi Max,
Could you include more information that shows what signature algorithm is used
based on the key size range and algorithm?
--Sean
On 12/11/16 9:53 PM, Wang Weijun
On 1/2/17 10:30 PM, Wang Weijun wrote:
Ping again.
Looks ok to me.
--Sean
On 12/27/2016 3:25 AM, Wang Weijun wrote:
Please take a review at
http://cr.openjdk.java.net/~weijun/8172017/webrev.00
On Solaris when launched by root, the rcache directory is a little
different.
I've manually te
Looks good to me.
--Sean
On 1/3/17 1:51 PM, Adam Petcher wrote:
Please review the following:
http://cr.openjdk.java.net/~apetcher/8172003/webrev.00/
This is a small conformance fix. Some XML crypto classes are throwing an
NPE instead of NoSuchProviderException when the provider is not found.
t updated in this webrev.
Thanks,
Xuelei
On 12/23/2016 7:52 AM, Sean Mullan wrote:
On 12/22/16 2:52 PM, Xuelei Fan wrote:
updated: http://cr.openjdk.java.net/~xuelei/8129988/webrev.02/
I think there are still some race conditions. For example:
264 TrustStoreDescriptor tempora
265 if (descriptor.equals(temporaryDesc) && (ks != null)) {
Not sure if JVM will optimize this, but probably better to check if ks != null
first, and avoid calling equals unless necessary:
265 if (ks != null && descriptor.equals(temporaryDesc)) {
Also, similar comment
8/webrev.05/
I re-write the getTrustedCerts() implementation. It looks more compact
now.
Thanks,
Xuelei
On 1/5/2017 8:13 AM, Sean Mullan wrote:
265 if (descriptor.equals(temporaryDesc) && (ks != null)) {
Not sure if JVM will optimize this, but probably better to check if
Looks good to me.
--Sean
On 1/6/17 3:52 AM, Wang Weijun wrote:
https://bugs.openjdk.java.net/browse/JDK-8165115
Thanks
Max
Please review this JDK 9 change to make the
SecurityManager::checkPackageAccess and checkPackageDefinition
implementations restrict access to the same set of internal JDK packages
as the module system.
This overall change will improve security by making these two mechanisms
consistent and red
Fix looks good to me.
--Sean
On 1/11/17 8:34 AM, Adam Petcher wrote:
Please review the following bug fix:
http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/
This fixes a bug in which a permission check would try to load resources
while the system class loader is being initialized. Resour
Looks ok, but is this for JDK 9? If so, we shouldn't be fixing P4 bugs
now since we are in Rampdown Phase 1.
--Sean
On 1/13/17 6:51 AM, Weijun Wang wrote:
Please review this code change:
diff --git
a/src/java.base/share/classes/sun/security/tools/keytool/Main.java
b/src/java.base/share/classe
On 1/13/17 4:09 AM, Weijun Wang wrote:
This class has a method called verifyTimestamp() but it's actually about
the validity period fields in a certificate. I found it quite misleading
because whenever I see timestamp I think of TSA and RFC 3161.
Are you OK with changing all occurrences of "time
On 1/12/17 3:53 PM, Mandy Chung wrote:
On Jan 11, 2017, at 5:34 AM, Adam Petcher
wrote:
Please review the following bug fix:
http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/
This fixes a bug in which a permission check would try to load
resources while the system class loader is bein
Looks good to me.
--Sean
On 1/15/17 8:41 PM, Weijun Wang wrote:
Please review the code change at
http://cr.openjdk.java.net/~weijun/8172529/webrev.02
The validator is updated to be a PKIXValidator of the
Validator.VAR_CODE_SIGNING variant. In order to have the same output
message and exit
On 1/13/17 2:38 AM, Mandy Chung wrote:
On Jan 9, 2017, at 11:25 AM, Sean Mullan
wrote:
Please review this JDK 9 change to make the
SecurityManager::checkPackageAccess and checkPackageDefinition
implementations restrict access to the same set of internal JDK
packages as the module system
On 1/19/17 10:28 AM, Adam Petcher wrote:
My last attempt to solve this problem didn't work because some classes
needed for string formatting were not loaded by init level 3 in some
cases. So I had to backtrack and try a different approach.
This patch avoids localization and message formatting wh
1501 - 1600 of 2385 matches
Mail list logo
