You should also add a test for MD2 and MD5 for the jarsigner -digestalg
option.
125 private static void testJarsignerSiginig(String sigAlg, String
alias)
typo: s/Siginig/Signing/
All else looks fine.
--Sean
On 8/4/20 11:13 PM, Hai-May Chao wrote:
Hi Muneer,
Updated webrev looks good
Please review this change to deprecate the following APIs:
java.security.cert.X509Certificate.getIssuerDN()
java.security.cert.X509Certificate.getSubjectDN()
java.security.cert.X509CRL.getIssuerDN()
java.security.cert.X509CertSelector.setIssuer(String)
java.security.cert.X509CertSelector.setSubje
Looks good.
--Sean
On 8/7/20 5:04 AM, abdul.kolarku...@oracle.com wrote:
Thanks Sean for the review.
Addressed your comments on new webrev -
http://cr.openjdk.java.net/~akolarkunnu/8248745/webrev.02/
-Muneer
On 06/08/20 8:00 pm, Sean Mullan wrote:
You should also add a test for MD2 and
On 8/13/20 7:04 AM, Сергей Цыпанов wrote:
Hello,
previously I've sent an email regarding removal of redundant assignments if
default values to volatile fields, see
https://mail.openjdk.java.net/pipermail/security-dev/2020-June/022137.html
There was a concern whether it's completely safe to rem
On 8/13/20 11:05 AM, Julia Boes wrote:
Hi Vipin,
Thanks for providing this fix, I'm happy to sponsor your change. To
complete the review, we still need someone to green light the remaining
changes below. I'm looping in net-dev and security-dev to have a look.
Bug: https://bugs.openjdk.java.n
https://bugs.openjdk.java.net/browse/JDK-6736490, there's
already one I've mentioned in previous mail:
https://bugs.openjdk.java.net/browse/JDK-8145680
Done: see https://bugs.openjdk.java.net/browse/JDK-8251548
--Sean
Regards,
Sergey Tsypanov
13.08.2020, 14:05, "Sean Mullan" :
On 8/13/2
On 8/13/20 1:21 PM, Jonathan Gibbons wrote:
---
old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java
2020-07-25 23:46:21.233726447 +0530
+++
new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java
2020-07-25 23:46:20.721720857 +0530
@@ -96,8 +96,6 @@
On the property wording, change "for LDAP connection" to "for an LDAP
connection".
Also, for the definition of the property, can you use the
"@systemProperty" annotation instead of "@code"? Does that work inside
the module-info.java file?
I added my name as Reviewer.
--Sean
On 7/30/20 6:14
@systemProperty to be consistent.
I think it is fine to do that as part of this fix.
--Sean
Updated webrev at: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v15/
Regards
Alexey
On 14 Aug 2020, at 14:50, Sean Mullan wrote:
On the property wording, change "for LDAP connection"
On 14/08/2020 14:18, Sean Mullan wrote:
On 8/14/20 8:41 AM, Alexey Bakhtin wrote:
Hello Sean,
Thank you for review.
I’ve changed wording and replaced @code with @systemProperty (tested,
it works for module-info.java)
Thanks. Now that you know it works, I think you should change the
other
On 8/14/20 2:46 PM, Vipin Sharma wrote:
Hi Sean,
All 3 instances of @exception in DHPrivateKey are now replaced with
@throws, added ProviderException similar to other constructor of
DHPrivateKey.
Looks good.
--Sean
In the bug report, the following fix was suggested:
"The fix to the issue should be simple, just move the initialization of
the verificationResults Map BEFORE the SecureRandom initialization in
JceSecurity.java"
Does that not work for some reason?
--Sean
On 8/19/20 1:13 AM, Xuelei Fan wrote
Ping ...
On 8/7/20 10:01 AM, Sean Mullan wrote:
Please review this change to deprecate the following APIs:
java.security.cert.X509Certificate.getIssuerDN()
java.security.cert.X509Certificate.getSubjectDN()
java.security.cert.X509CRL.getIssuerDN()
java.security.cert.X509CertSelector.setIssuer
On 8/25/20 12:33 PM, Anders Rundgren wrote:
The command
keytool -genkeypair -keyalg ec -keysize 256 -dname "CN=me" -keystore
mycert.jks
using JDK 11 generates the following signature:
220: SEQUENCE
{
222: OBJECT IDENTIFIER ecdsa-with-Sha256 (1.2.840.10045.4.3.2)
232:
reference RFC 2253 several times. I have changed them to be consistent
so that the first reference in each method is a link to 2253, while the
rest of them are text.
--Sean
Xuelei
On 8/21/2020 9:24 AM, Sean Mullan wrote:
Ping ...
On 8/7/20 10:01 AM, Sean Mullan wrote:
Please review this cha
8/21/2020 11:01 AM, Xuelei Fan wrote:
Looks fine to me.
Just a trivial format comment. Some use link for "RFC 2253", some do
not. It's OK. And it's good as well if you want to use a uniform style.
Xuelei
On 8/21/2020 9:24 AM, Sean Mullan wrote:
Ping ...
On 8/7/20 1
On 9/9/20 1:16 AM, Anders Rundgren wrote:
I may (surely) be wrong but changing the API to return
NamedParameterSpec should not break any existing code based on the
Oracle provider.
Whether it continues to work when someone is using a specific provider
is not relevant. This is a Java SE API, an
On Tue, 15 Sep 2020 01:34:56 GMT, Valerie Peng wrote:
>> Could someone please help review this RFE?
>>
>> Enhance default JDK providers except SunPKCS11 with signatures using SHA-3
>> family of digests. SunPKCS11 provider will
>> be updated separately (JDK-8242332).
>> This changes covers SUN,
On Thu, 17 Sep 2020 08:09:31 GMT, Сергей Цыпанов
wrote:
> Hello,
>
> is it possible to have a code review for the changes proposed in JDK-8251548
> (originally contributed via
> https://mail.openjdk.java.net/pipermail/security-dev/2020-June/022137.html)?
> Sean Mullan has cr
On Tue, 22 Sep 2020 00:18:07 GMT, Anthony Scarpino
wrote:
>> This change removes the native elliptic curves library code; as well as, and
>> calls to that code, tests, and files
>> associated with those libraries. The makefiles have been changed to remove
>> from all source builds of the ec c
On Fri, 25 Sep 2020 19:57:49 GMT, Anthony Scarpino
wrote:
>> Hi,
>>
>> I need a quick review for two changes. The primary is a failure that shows
>> up on linux-aarch64 because the systems do
>> not have NSS. The default was to allow all curves tested, which before the
>> native library rem
On Fri, 2 Oct 2020 16:21:47 GMT, Rajan Halade wrote:
> 8239105 : Add exception for expiring Digicert root certificates to
> VerifyCACerts test
Looks good. Shouldn't we be seeing mach5 test failures from this though? I
didn't see any failures.
-
Marked as reviewed by mullan (Revie
On Thu, 1 Oct 2020 20:02:34 GMT, Weijun Wang wrote:
> Default algorithms are bumped to be based on PBES2 with AES-256 and SHA-256.
> Please also review the CSR at
> https://bugs.openjdk.java.net/browse/JDK-8228481.
test/jdk/sun/security/mscapi/VeryLongAlias.java line 51:
> 49: public stati
On Thu, 1 Oct 2020 20:02:34 GMT, Weijun Wang wrote:
> Default algorithms are bumped to be based on PBES2 with AES-256 and SHA-256.
> Please also review the CSR at
> https://bugs.openjdk.java.net/browse/JDK-8228481.
test/lib/jdk/test/lib/security/DerUtils.java line 1:
> 1: /*
Is this test chan
On Tue, 6 Oct 2020 16:29:55 GMT, Rajan Halade wrote:
>> 8254081: java/security/cert/PolicyNode/GetPolicyQualifiers.java fails due to
>> an expired certificate
>
> Rajan Halade has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8254081: Use Da
On Fri, 2 Oct 2020 19:07:20 GMT, Weijun Wang wrote:
>> test/jdk/sun/security/mscapi/VeryLongAlias.java line 51:
>>
>>> 49: public static void main(String[] args) throws Throwable {
>>> 50:
>>> 51: // Using the old algorithms to make sure the file is recognized
>>
>> Do we also want
On Thu, 8 Oct 2020 14:21:09 GMT, Weijun Wang wrote:
>> CSR updated. More description, and iteration counts lowered to 1. Will
>> update code soon.
>
> New commit updating ic to 1. I also created separate constants for
> DEFAULT_CERT_PBE_ITERATION_COUNT and
> DEFAULT_KEY_PBE_ITERATION_CO
In the Summary and Solution sections, can you be more specific as to
what TLS versions will be supported?
Can you also show what the order of signature schemes is before and
after the change, for each TLS version? I think this would make it more
clear about what the priority of the new schemes
Yes, that is a bug. Do you want to file a bug report or would you like
us to file on one your behalf?
Thanks,
Sean
On 10/23/20 10:56 AM, Kai wrote:
Hi,
I ran into a NPE while validating a certificate chain with the latest
JDK 11 using a TrustAnchor that has been created using the
TrustAncho
On Wed, 28 Oct 2020 20:56:31 GMT, Weijun Wang wrote:
> I regret adding the `directsign` property/option to JarSigner/jarsigner. See
> the bug for details.
Looks good.
-
Marked as reviewed by mullan (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/915
On Fri, 9 Oct 2020 01:33:38 GMT, Weijun Wang wrote:
>> Default algorithms are bumped to be based on PBES2 with AES-256 and SHA-256.
>> Please also review the CSR at
>> https://bugs.openjdk.java.net/browse/JDK-8228481.
>
> Weijun Wang has updated the pull request incrementally with one additiona
JDK-806769 doesn't exist, can you double-check what issue you think
caused this? Looks like you are missing a digit.
Thanks,
Sean
On 9/24/15 10:46 PM, David Black wrote:
As I do not have an account on https://bugs.openjdk.java.net, yes I have
submitted a standard oracle java bug report, I thou
Looks fine.
--Sean
On 9/25/15 1:27 AM, Amanda Jiang wrote:
Hi Sean,
Thanks for reviewing this, new comments has been addressed, please
check the webrev below:
http://cr.openjdk.java.net/~amjiang/8050402/webrev.03/
Thanks,
Amanda
On 9/24/15, 12:21 PM, Sean Mullan wrote:
Hi Amanda,
Just a
suggestion of adding a query API for provider configuration.
I added a trivial regression test for the uninitialized PKCS11 provider
as well.
Webrev: http://cr.openjdk.java.net/~valeriep/8130648/webrev.01/
Will update CCC once the webrev review is done.
Thanks,
Valerie
On 9/24/2015 11:24 AM, Sean Mu
Looks good, just a couple of comments:
AlgorithmId: can you use braces around the conditional statements on
lines 1008-1017?
Function: are you missing an @modules tag for the jarsigner module?
Options.java: why not use the JarSigner API here instead of the
jarsigner tool?
--Sean
On 09/21/
Function: are you missing an @modules tag for the jarsigner module?
Which one? I thought @modules is only used if you want to call
non-exported classes.
Ok, never mind then.
Options.java: why not use the JarSigner API here instead of the
jarsigner tool?
This test is to make sure jarsigne
Please review this fix to modify the TrustManagerFactory implementation
to create a single instance of the cacerts or jssecacerts KeyStore. This
significantly improves performance in a multithreaded environment.
The code has been refactored a bit to move common code into a few
private methods.
iom
--Sean
Thanks,
Xuelei
On 9/30/2015 2:07 AM, Sean Mullan wrote:
Please review this fix to modify the TrustManagerFactory implementation
to create a single instance of the cacerts or jssecacerts KeyStore. This
significantly improves performance in a multithreaded environment.
The code has
Looks fine to me.
--Sean
On 10/1/15 12:02 PM, Jamil Nimeh wrote:
Hello all,
While looking at CertStatusReqItemV2, I came across a left-over from
early prototyping. The class currently implements StatusRequest, but it
really shouldn't. It never caused a problem because StatusRequest
requires
Looks fine to me, though I have one question below.
On 10/7/15 2:19 PM, Chris Hegarty wrote:
This primary motivation behind this bug [1] is the clearing out of
sun.misc, in preparation for JEP 260 [2].
sun.misc.IOUtils is a JDK internal convenience utility class that
provides a single method th
Couple of comments:
- SolarisProviderTest is too generic for me. I would call this
"PreferredProviderTest". Also, that way it can be enhanced over time if
we add preferred providers for other OSes.
- In the error messages:
s/Get/Got/
s/Return/Returned/
- Similarly, "SecurityPropertyNegative
Please review this fix for a regression that removes the requirement
that a certificate's Authority Key Identifier must match the issuing
certificate's Subject Key Identifier when building a certificate chain.
The certificate chain validation algorithm in RFC 5280 does not require
that the AKI
Looks good.
Thanks,
Sean
On 11/10/2015 03:36 AM, Tim Du wrote:
Hi Sean:
Thanks for reviewing the codes. Updated them follow your comments, see
http://cr.openjdk.java.net/~fyuan/tim/8076359/webrev.02/ ,please help to
review them again.
Regards
Tim
On 11/10/2015 8:18 AM, Sean Mullan wrote
Hi Max,
Still reviewing, but a couple of initial comments ..
On 11/09/2015 09:54 AM, Wang Weijun wrote:
Hi All
The following is API/SPI to support NIST 800-90A DRBGs. The JEP is at
https://bugs.openjdk.java.net/browse/JDK-8051408
Some notes before the text:
1. Mainly, new methods are add
On 11/12/2015 07:58 PM, Wang Weijun wrote:
What happens if configure is called more than once, or
simultaneously by more than one thread?
The state is reset. The last one rules. The implementation can be
made synchronized.
* This method can be called multiple times. After each call, this *
{@co
Additionally, in JDK 9 we have added a new configure method to the
java.security.Provider class that allows you to configure an underlying
provider with an additional argument. The SunPKCS11 implementation has
been enhanced to support this method.
So, instead of depending on the internal sun.s
/p11guide.html#Config
If I understand correctly, we cannot really anticipate the
sun.x-encapsulation in jdk9? For the moment we just need to keep using
SunPKCS11 and migrate to the code below when releasing for java 9?
Correct.
--Sean
Many thanks,
Glen
Op 16/11/2015 om 16:46 schreef Sean Mullan
On 11/17/2015 09:10 AM, Wang Weijun wrote:
Hi All
The test has failed a lot recently. Please review the change:
diff --git a/test/ProblemList.txt b/test/ProblemList.txt
--- a/test/ProblemList.txt
+++ b/test/ProblemList.txt
@@ -234,6 +234,7 @@
sun/security/tools/jarsigner/warnings/BadKeyUsageT
On 11/16/2015 08:00 PM, Wang Weijun wrote:
On Nov 16, 2015, at 11:46 PM, Sean Mullan wrote:
Provider p = Security.getProvider("SunPKCS11");
p.configure("/opt/bar/cfg/pkcs11.cfg");
p = p.configure("/opt/bar/cfg/pkcs11.cfg");
The spec for the meth
On 11/13/2015 08:43 PM, Wang Weijun wrote:
On 2015年11月14日, at 上午1:56, Sean Mullan wrote:
On 11/12/2015 07:58 PM, Wang Weijun wrote:
What happens if configure is called more than once, or
simultaneously by more than one thread?
The state is reset. The last one rules. The implementation c
Looks good, just a couple of minor comments:
In JarSigner.Builder.getDefaultSignatureAlgorithm, change the word
"bigger" to "greater than".
In AlgorithmId.getDefaultSigAlgForKey, I think you can remove the last
sentence ("Remember ...") - this seems like a ToDo note to yourself
which has bee
On 11/18/2015 09:54 PM, Wang Weijun wrote:
In AlgorithmId.getDefaultSigAlgForKey, I think you can remove the
last sentence ("Remember ...") - this seems like a ToDo note to
yourself which has been done.
It's a reminder if we update it again in the future.
Ok.
It makes me feel a little uncomf
On 11/19/2015 08:41 AM, Wang Weijun wrote:
On Nov 18, 2015, at 9:32 PM, Sean Mullan wrote:
The getInstance methods can now take a SecureRandomParameterSpec object (rather
than an AlgorithmParameterSpec). They should throw
InvalidAlgorithmParameterException (not IllegalArgumentException) if
On 11/19/2015 07:23 PM, Wang Weijun wrote:
On Nov 20, 2015, at 1:11 AM, Sean Mullan wrote:
>>
>>However, I cannot get it working, and I found difficulties understanding the
EngineDescription inner class inside Provider.java.
>>
>>1. For each engine that can take
This looks good, just a few comments:
KeyStoreUtil:
79 if (!ca.getSubjectDN().equals(end.getIssuerDN())) {
Use getSubjectX500Principal instead of getSubjectDN as the DN matching
algorithm is more precise.
Resources:
246 "The %1$s algorithm used as %2$s is considered
Looks fine to me.
--Sean
On 11/23/2015 10:57 AM, joe darcy wrote:
Hello,
Please review the patch below to problem list
sun/security/pkcs/pkcs8/PKCS8Test.java
on Solaris until the underlying issues (JDK-8143377) are addressed.
Thanks,
-Joe
diff -r aa0621638103 test/ProblemList.txt
---
Looks good - although you could replace the MD5 fingerprints with the
SHA256 fingerprints in the test files for some additional testing.
--Sean
On 11/23/2015 08:00 PM, Wang Weijun wrote:
Hi All
Please review a code change at
http://cr.openjdk.java.net/~weijun/8141457/webrev.00/
SHA-256
The fix looks fine to me. For testing, can you create a test that uses a
custom java.security file with "#ifndef solaris-sparc" in it, and check
whether the property is used or not depending on what system is being
tested?
--Sean
On 11/24/2015 06:10 AM, Magnus Ihse Bursie wrote:
On 2015-11-2
You should change the comment above the calls to setupPrivateKeyAndChain
as it still reflects the previous behavior. Also, should this change
only be applicable to TLS 1.2?
--Sean
On 11/29/2015 08:55 AM, Xuelei Fan wrote:
Hi,
Please review the fix for JDK-8136442:
http://cr.openjdk.java
Looks good.
--Sean
On 11/26/2015 02:12 AM, Wang Weijun wrote:
Please review the fix at
http://cr.openjdk.java.net/~weijun/8144107/webrev.00/
The recent JarSigner API changeset includes some tests in jdk/security but the
directory is not included in any test group. This fix adds it into
On 11/30/2015 11:13 AM, Xuelei Fan wrote:
You should change the comment above the calls to setupPrivateKeyAndChain
>as it still reflects the previous behavior.
Oops, forgot the update the comment.
Updated:
http://cr.openjdk.java.net/~xuelei/8136442/webrev.01/
Looks good.
>Also, should
SSLParameters.java
649 applicationProtocols = protocols.clone();
You should clone the parameters before checking if they are valid. Move
this to line 642, and check the validity of the cloned array. Also, use
a temporary variable for the clone, so as not to pollute the
applicationProt
serverReady doesn't need to be volatile anymore.
Looks good otherwise.
--Sean
On 12/01/2015 05:48 AM, Xuelei Fan wrote:
Hi,
Please review this test update:
http://cr.openjdk.java.net/~xuelei/8144313/webrev.00/
In test/javax/net/ssl/SSLSession/SessionTimeOutTests.java, the update of
"ser
On 11/25/2015 09:39 PM, Wang Weijun wrote:
Updated at http://cr.openjdk.java.net/~weijun/8141457/webrev.01/.
I was lazy last time.
Looks good.
--Sean
--Max
On Nov 24, 2015, at 8:15 PM, Sean Mullan wrote:
Looks good - although you could replace the MD5 fingerprints with the SHA256
Wang Weijun wrote:
On Nov 25, 2015, at 11:04 PM, Sean Mullan wrote:
The fix looks fine to me. For testing, can you create a test that uses a custom
java.security file with "#ifndef solaris-sparc" in it, and check whether the
property is used or not depending on what system is bein
I opened a backport for this issue for a JDK 8 update release, see:
https://bugs.openjdk.java.net/browse/JDK-8143905
The backport should be relatively straightforward, but I am not sure yet
when or what release the fix will appear in.
--Sean
On 11/19/2015 04:53 AM, Basabendra Misra wrote:
H
On 12/04/2015 09:41 AM, Xuelei Fan wrote:
Hi,
Please review the test update for JDK-8141703:
http://cr.openjdk.java.net/~xuelei/8141703/webrev.00/
The test, sun/net/www/protocol/https/HttpsURLConnection/B6216082.java,
need to start a server and proxy, and then make https connection over
the
Looks fine to me.
--Sean
On 12/03/2015 09:18 AM, Artem Smotrakov wrote:
I sent a wrong version of webrev, please use the following one
http://cr.openjdk.java.net/~asmotrak/8140470/webrev.01/
Artem
On 12/03/2015 05:10 PM, Artem Smotrakov wrote:
Hello,
Please review this small fix which upda
Fix looks good, interesting issue, though I wonder if there is a better
locking scheme, but probably a question for another time.
--Sean
On 12/05/2015 07:03 PM, Xuelei Fan wrote:
Hi,
Please review the fix for JDK-8141651:
http://cr.openjdk.java.net/~xuelei/8141651/webrev.00/
In JDK 9,
Bug: https://bugs.openjdk.java.net/browse/JDK-8144784
The @Deprecated annotation on a package is a no-op in terms of affecting
the set of deprecation warnings the compiler produces. This has been
clarified in the JLS and specification for java.lang.Deprecated in 9.
Thus, we should remove the
On 12/09/2015 04:51 PM, Mandy Chung wrote:
On Dec 9, 2015, at 1:43 PM, Sean Mullan wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8144784
The @Deprecated annotation on a package is a no-op in terms of affecting the
set of deprecation warnings the compiler produces. This has been
On 12/10/2015 01:14 PM, Mandy Chung wrote:
On Dec 10, 2015, at 7:53 AM, Sean Mullan
wrote:
Max asked me to add the com.sun.jarsigner package to this bug,
which also has an unnecessary @Deprecated annotation. I also made a
few tweaks to the deprecation wording here and there, so a webrev
is
The DrbgParameters class has 7 parameters, most of which are optional. A
typical use case might involve lots of null parameters:
DrbgParameters params = new DrbgParameters(null, null, 256, false,
false, nonce, null);
That seems awkward, and you have be overly careful to map the right
value t
Hi Xuelei,
For JDK 9, the EC impl is defined to be in its own module
(jdk.crypto.ec). How does it affect this fix if that module is not
available/installed?
--Sean
On 12/01/2015 07:49 AM, Xuelei Fan wrote:
Hi,
Please review the fix for JDK-8133070:
http://cr.openjdk.java.net/~xuelei/8
On 12/03/2015 09:07 PM, Wang Weijun wrote:
Or if this is too much, we can at least do the X509Extension part. If
CertificateRequest is needed one day, we can create a new method
Builder.certificateRequest() that returns it and deprecate the
current request() method.
Or use certificateRequest() t
This fix looks fine to me. Please add a "noreg-self" label to the bug.
--Sean
On 12/11/2015 05:50 AM, Bhanu Gopularam wrote:
Hi all,
Please review a fix for following bug:
Bug Id - https://bugs.openjdk.java.net/browse/JDK-8129567
Issue – Few tests are using all zero IV for GCM parameter spec
rrent class does.
--Sean
In this case, the algorithm will only be known after it is used for a specific
DRBG, for example, SHA-256 for HashDRBG, and AES-256 for CtrDRBG.
--Max
On Dec 15, 2015, at 12:05 AM, Sean Mullan wrote:
The DrbgParameters class has 7 parameters, most of which are option
, Sean Mullan wrote:
Hi Xuelei,
For JDK 9, the EC impl is defined to be in its own module
(jdk.crypto.ec). How does it affect this fix if that module is not
available/installed?
The SunJSSE provider would not support dynamically loading of crypto
providers/modules. At present, there are two
The fix looks good, although this test is already on the ProblemList due
to JDK-8074580. Do you know if that bug is caused by the same issue? The
underlying PKCS11 error is different (maybe due to a different Solaris
version?), but it looks like an identical stack trace. It would be good
to als
This explanation makes sense to me and the fix looks fine.
--Sean
On 12/17/2015 01:51 AM, Xuelei Fan wrote:
On 12/17/2015 7:52 AM, Bradford Wetmore wrote:
On 12/16/2015 3:22 PM, Xuelei Fan wrote:
On 12/17/2015 3:14 AM, Bradford Wetmore wrote:
The change itself looks ok, but a question on t
, Sean Mullan wrote:
Here are a few other other comments on the code:
SSLContextImpl:
- I noticed that SSLContext.init does not specify how it handles empty
arrays, and you have changed the code so that an empty TrustManager
array is treated like they are null - is this change in behavior a
Looks fine to me.
> On Dec 25, 2015, at 10:53 AM, Xuelei Fan wrote:
>
> Hi,
>
> Anyone available for a quick review?
>
> http://cr.openjdk.java.net/~xuelei/8146197/webrev.00/
>
> A test failure caused by the removal of BASE64Decoder. Updated to use
> java.util.Base64.
>
> Thanks,
> Xuele
On 01/04/2016 09:02 AM, Chris Hegarty wrote:
sun.misc.VM provides a low-level interface for a small number
of specific operations with the VM. In preparation for JEP 260,
this class should be moved out of sun.misc and located in a
non-exported package [.
http://cr.openjdk.java.net/~chegar/814554
On 01/04/2016 09:14 AM, Chris Hegarty wrote:
Note: as in other areas some tests that require access to
internal APIs have been updated to use types from a more
stable package, sun.security.x509.
Not sure what you mean - which tests do you mean and why is
sun.security.x509 related to this issue?
, and would like to continue with fix for public exponent issue
as reported in JDK-8129560.
Please let me know.
Sure, that is fine.
--Sean
Thank you,
Bhanu
-Original Message-
From: Anthony Scarpino
Sent: Saturday, December 19, 2015 3:34 AM
To: Sean Mullan
Cc: Bhanu Gopularam; security
Here are some more comments on the API:
* EntropyInput:
29 * An interface of a source of entropy input.
"interface" is implied, so you can just say "A source of entropy input."
Also, I think this interface should be called "EntropySource". To me,
"Input" means the byte array that is alread
On 01/04/2016 08:17 PM, Wang Weijun wrote:
On Jan 5, 2016, at 6:59 AM, Sean Mullan
wrote:
Here are some more comments on the API:
* EntropyInput:
29 * An interface of a source of entropy input.
"interface" is implied, so you can just say "A source of entropy
input."
Here are some more comments on the API. I will send some comments on the
impl next.
* DrbgParameters
38 * A DRBG mechanism should extend this class.
Is this sentence necessary? None of the builtin DRBG mechs extend this
class.
175 * If this method is not called, the implementat
On 01/05/2016 12:28 PM, Seshadri, Usha wrote:
Hi,
I am using Java 8, and am trying to configure JVM to go to CRL for
revocation checking.I didn’t see any parameter in java.security to
enable CRL revocation checking, although there are parameters to
configure OCSP.
I tried setting these two para
ent. Builder still using byte[] which is PKCS
#10 encoded.
Many thanks to Mandy, Larry, and Sean for your comments. Mike, we will add more
methods later when they are needed.
--Max
On Dec 15, 2015, at 11:53 PM, Sean Mullan wrote:
On 12/03/2015 09:07 PM, Wang Weijun wrote:
Or if this
Please update copyrights to include 2016. Otherwise, looks fine to me.
--Sean
On 01/08/2016 02:54 AM, Bhanu Gopularam wrote:
Hi all,
Please review a fix for following bug:
Bug Id -https://bugs.openjdk.java.net/browse/JDK-8133085
Issue – Some security regression tests are directly instantiati
Please review this fix for a memory leak in the ProtectionDomain cache
(which maps each ProtectionDomain to their granted
PermissionCollection). The memory leak only occurs if custom permissions
are used in a policy file.
http://cr.openjdk.java.net/~mullan/webrevs/8085903/webrev.00/
Custom pe
On 01/07/2016 10:38 PM, Wang Weijun wrote:
On Jan 8, 2016, at 6:06 AM, Sean Mullan
wrote:
* CertificateFactorySpi
Need more details on how inStream is parsed.
I thought a "@see CertificateFactory#generateCertificateRequest" is
enough. I do noticed that
Certificate
ional check for this case in the PDCache.put
method, and it instead uses the Map.replace method. Updated webrev:
http://cr.openjdk.java.net/~mullan/webrevs/8085903/webrev.01/
--Sean
On 01/08/2016 03:06 PM, Sean Mullan wrote:
Please review this fix for a memory leak in the ProtectionDomain
Hi Ivan,
On 01/12/2016 09:38 AM, Ivan Gerasimov wrote:
Hi Sean!
On 12.01.2016 16:26, Sean Mullan wrote:
I received a private comment that there may be cases where the map's
value is reclaimed by the garbage collector, but the key still exists.
If that ProtectionDomain is subsequently use
fresh())
which should cause a new cache to be created.
Let me do some more testing around this, and see if I can check
performance and see what is better.
Thanks,
Sean
Xuelei
On 1/12/2016 11:01 PM, Sean Mullan wrote:
Hi Ivan,
On 01/12/2016 09:38 AM, Ivan Gerasimov wrote:
Hi Sean!
On 12.01.20
-8055753
On 01/12/2016 11:02 AM, Sean Mullan wrote:
On 01/12/2016 10:26 AM, Xuelei Fan wrote:
I think hashMap.put() may be similar or more effective than
hashMap.putIfAbsent().
Ok, I think I see what you are trying to say.
The common case is that the putIfAbsent method is going to succeed (i.e.
the
A few more comments for now, but I'll need another day or so to finish
my review:
* General
Use @throws instead of @exception
* X509Certificate
lines 572-585 were removed, but where was it copied? It is not in
GeneralName and probably should not be unless we add a toString method.
847
addAuthorityKeyIdentifierExtension();
X509Certificate.Builder addSubjectKeyIdentifierExtension();
2. X509Extension getRawExtensionValue(String oid)
3. Spec changes we discussed.
Still one TODO in X509Certificate.Builder subject(String name).
Some comments below in line.
On Jan 13, 2016, at 5:58 AM, Sean Mullan
Looks good to me.
--Sean
On 01/14/2016 05:05 AM, Chris Hegarty wrote:
The "stopThread” RuntimePermission is granted by default. The Thread.stop
methods have been deprecated for more than 15 years. It seems reasonable,
in a major release, to remove the default grant of stopThread.
diff --git a/
1301 - 1400 of 2385 matches
Mail list logo
