On 02/13/2013 01:22 PM, Vincent Ryan wrote:
Latest webrev:
http://cr.openjdk.java.net/~vinnie/8007755/webrev.01/
Looks good.
Also, this will require a CCC, so you won't be able to fix this now, but
the DomainLoadStoreParameter should be a standalone class, since it is
keystore-type speci
Looks good to me too.
--Sean
On 02/19/2013 12:42 PM, Chris Hegarty wrote:
Looks ok to me.
-Chris.
On 02/19/2013 05:16 PM, John Zavgren wrote:
Greetings:
I posted a webrev image:
http://cr.openjdk.java.net/~jzavgren/8008107/webrev.01/,
of a change that I made to the native source code file:
Changeset: 267bca6af07e
Author:jzavgren
Date: 2013-02-19 15:31 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/267bca6af07e
8008107: [parfait] Use after free of pointer in
jdk/src/share/native/sun/security/pkcs11/wrapper/p11_convert.c
Reviewed-by: mullan, chegar
! src/share/
Hi,
On 02/21/2013 07:13 AM, Neil Richards wrote:
Hi,
The change made for the RFE 7019834 [1] [2] [3] is built upon the
assertion that:
"All PrincipalComparator implementations should already
implement Principal".
However, the Javadoc for com.sun.security.auth.PrincipalComparat
The security related ones look ok to me.
--Sean
On 02/21/2013 01:46 PM, Alan Bateman wrote:
Joe Darcy recently added @jdk.Supported [1] to make it possible to
identify JDK-specific APIs.
I'd like to add this to a number of APIs in the com.sun namespace to
make it obvious these are "supported"
On 02/25/13 07:56, Tom Hawtin wrote:
On 25/02/2013 12:07, Alan Bateman wrote:
I would like to change these methods so that they behave as if the
permission check fails. I think this is the approach of least-surprise
as it's not possible to grant anyone AWTPermission when the permission
type doe
On 02/25/13 10:52, Alan Bateman wrote:
On 25/02/2013 15:22, Sean Mullan wrote:
Yes, good point, but Alan has corrected that, refresh the webrev.
I just had one comment:
- I think you need to run the test in it's own JVM, since it sets an SM.
--Sean
Yes, Tom is right an
On 02/25/13 11:32, Alan Bateman wrote:
On 25/02/2013 16:04, Sean Mullan wrote:
But there can be only one SM, so it could potentially affect other
tests in different threads that depend on an SM. (If 2 tests that set
their own SM ran in the same VM, potential issues would result, right
On 02/27/2013 06:24 AM, Alan Bateman wrote:
On 26/02/2013 18:36, Neil Richards wrote:
Hi Sean,
Thanks for your quick response.
I admit, I hadn't spotted the description of the policy file syntax to
which you point.
(In my defence, it's a lot easier to overlook than the explicit wording
that I
Please review this simple fix for parsing wildcard principal names in
policy files which is a regression caused by 7019834 [1].
bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008908
webrev:
http://cr.openjdk.java.net/~mullan/webrevs/8008908/webrev.00/
Thanks,
Sean
[1] http://bug
Changeset: 1652ac7b4bfd
Author:mullan
Date: 2013-03-01 16:12 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1652ac7b4bfd
8008908: Access denied when invoking Subject.doAsPrivileged()
Summary: wildcard principal names are not processed correctly
Reviewed-by: xuelei
! src/shar
Looks good.
--Sean
On 03/07/2013 04:04 AM, Weijun Wang wrote:
Hi
Bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009617
Original bug:
https://bugs.openjdk.java.net/show_bug.cgi?id=100304
Webrev:
http://cr.openjdk.java.net/~weijun/8009617/webrev.00
I've added a few li
Looks good to me. I can push this for you later today.
--Sean
On 03/12/2013 04:12 PM, John Zavgren wrote:
Greetings:
I posted a webrev image of a (very minor) bug fix that eliminates a
reference to freed memory.
http://cr.openjdk.java.net/~jzavgren/8007637/webrev.01/
Thanks!
John
Please review this fix for a NullPointerException when checking
revocation status of certificates:
webrev:
http://cr.openjdk.java.net/~mullan/webrevs/8010112/webrev.00/
The bug is not available online for some reason, so here are the
relevant details:
There were 2 issues that needed to be
This change looks fine to me.
--Sean
On 03/13/2013 03:13 AM, Weijun Wang wrote:
http://cr.openjdk.java.net/~weijun/8009970/webrev.00
I was checking for krb5 permissions and noticed this. There is really no
need for a permission to access AuthResources strings in these login
modules.
Also chan
s,
Sean
Paul
On 9/11/18, 12:49 PM, "core-libs-dev on behalf of Sean Mullan"
wrote:
Hi Paul,
Thank you for bringing this issue to our attention. While we agree that
this does indeed seem like an issue that should be addressed, it is
quite late in the JDK
On 9/14/18 1:17 PM, Roger Riggs wrote:
Hi Sean,
Looks good.
I would quibble with System.java:335-6
"Java virtual machine does not allow a security manager"
I would say only "a security manager is not allowed to be set dynamically."
There is no need to identify the Java virtual machine. The
On 9/14/18 9:28 AM, David Lloyd wrote:
The security manager is legacy these days and I think we need to figure
out a plan how to deprecate and eventually bury it. I have no idea how
many releases or years that might take but the proposal here is a
profitable first step. It's easy to imagine follo
Looks ok to me. The bug needs an appropriate noreg label.
--Sean
On 9/19/18 12:05 PM, Mikael Vidstedt wrote:
Please review this change which fixes a Solaris/SPARC build issue:
bug: https://bugs.openjdk.java.net/browse/JDK-8210912
webrev:
http://cr.openjdk.java.net/~mikael/webrevs/8210912/web
Still reviewing but here are some initial comments.
It seems this is more than a fix for JDK-8076190. It also adds
configuration properties for the PKCS12 algorithms. I think you should
expand the scope/description of the issue to include that.
* HmacPKCS12PBECore.java
The class description
On 9/23/18 9:42 AM, Weijun Wang wrote:
On Sep 22, 2018, at 2:49 AM, Sean Mullan wrote:
Still reviewing but here are some initial comments.
It seems this is more than a fix for JDK-8076190. It also adds configuration
properties for the PKCS12 algorithms. I think you should expand the
scope
t perfect but is probably the best option. Right now it reads too much
like a brainstorming session :)
--Sean
On 9/25/18 6:49 AM, Weijun Wang wrote:
Webrev updated at http://cr.openjdk.java.net/~weijun/8076190/webrev.03/.
Mostly spec changes. The test is enhanced a little to check for macA
On 9/27/18 1:58 AM, Weijun Wang wrote:
All others accepted.
1122 keystore.pkcs12.certProtectionAlgorithm = PBEWithSHA1AndRC2_40
Shouldn't this be named certPbeAlgorithm so that it matches
certPbeIterationCount? Same comment about keyProtectionAlgorithm.
Unfortunately we already had "keystor
gt; --Max
>
>> On Sep 27, 2018, at 9:43 PM, Sean Mullan wrote:
>>
>> On 9/27/18 1:58 AM, Weijun Wang wrote:
>>> All others accepted.
>>>> 1122 keystore.pkcs12.certProtectionAlgorithm = PBEWithSHA1AndRC2_40
>>>>
>>>>
KCS12".
Or, shall we comment out the lines in java.security? They are indeed useless
because default values are already hardcoded in source files.
--Max
On Sep 27, 2018, at 10:29 PM, Sean Mullan wrote:
It seems odd to support both. Once we put that into the code it’s very hard to
tak
do you think?
Thanks
Max
On Sep 28, 2018, at 12:22 AM, Sean Mullan wrote:
The keystore.pkcs12.keyProtectionAlgorithm property was introduced in JDK 8. I
don't think there are many apps using it.
Thus, I would make a decision on what you think the best solution is long-term
and then mak
java.net/pipermail/security-dev/2018-September/018193.html
On 9/13/18 4:02 PM, Sean Mullan wrote:
This is a SecurityManager related change which warrants some additional
details for its motivation.
The current System.setSecurityManager() API allows a SecurityManager to
be set at run-ti
On 10/1/18 8:02 PM, Weijun Wang wrote:
On Oct 2, 2018, at 2:49 AM, Sean Mullan <mailto:sean.mul...@oracle.com>> wrote:
Looks good. After you update the CSR with these changes, I can review it.
Sure.
How do you think of the following change? Shall I also add it?
Yes.
*diff --
On 10/2/18 1:05 PM, Mandy Chung wrote:
I'm not a fan of using double == which is not obvious to catch the
typo. I think the `==` syntax may not be commonly known either (I
suspect it's seldom for a user to override java.security.policy rather
than augmenting it).
Have you considered using si
On 10/2/18 2:47 PM, Alan Bateman wrote:
On 02/10/2018 16:34, Sean Mullan wrote:
Hello,
Thanks for all the comments so far, and the interesting discussions
about the future of the SecurityManager. We will definitely return to
those discussions in the near future, but for now I have a second
Looks fine to me.
--Sean
On 9/24/18 11:59 PM, Weijun Wang wrote:
Ping again.
On Sep 5, 2018, at 12:17 PM, Weijun Wang wrote:
I ran javadoc on test/lib so I can learn the useful helper classes, and find
out SecurityTools.java has no javadoc at all.
Please review this change
http://cr.o
the issue and spec changes:
https://bugs.openjdk.java.net/browse/JDK-8203316
Thanks,
Sean
Forwarded Message
Subject: Re: RFR (12): 8191053: Provide a mechanism to make system's
security manager immutable
Date: Tue, 2 Oct 2018 11:34:09 -0400
From: Sean Mullan
Organization: Ora
hanks,
Sean
On 03/10/2018 13:12, Sean Mullan wrote:
For those of you that are not also subscribed to security-dev, this is
mostly FYI, as the review is winding down, but if you have any
comments, let me know.
This change will add new token options ("allow" and &qu
module.
I have kept it simple and added these 2 sentences: "If a class name is
specified, it must be java.lang.SecurityManager or a public subclass and
have a public no-arg constructor. The class is loaded by the system
class loader." We could revisit this later if it should be more pre
On 10/5/18 6:40 AM, Alan Bateman wrote:
The only issue I see is the statement "The class is loaded by the system
class loader ..." as it's actually the built-in application class loader.
Is the "built-in application class loader" something that is specified
somewhere else? I'd like to link to
On what version of Java 8 does it work?
I am not sure what the problem is without additional information.
Also, have you tried running with -Djava.security.debug=all? Did
anything unusual (exceptions, etc) get logged?
I would also suggest filing a bug with a reproducible test case, if
possib
Looks good to me.
--Sean
On 10/8/18 11:24 AM, Claes Redestad wrote:
Hi,
JDK-8207768 cause a noticeable regression in a subset of our startup
tests due eagerly loading security.properties for getting a property
that's only used in exceptional circumstances. Ensuring Manifest doesn't
eagerly
Max
On Oct 3, 2018, at 12:51 AM, Sean Mullan wrote:
On 10/1/18 8:02 PM, Weijun Wang wrote:
On Oct 2, 2018, at 2:49 AM, Sean Mullan wrote:
Looks good. After you update the CSR with these changes, I can review it.
Sure.
How do you think of the following change? Shall I also add it?
Yes.
The first sentence is a bit terse. Suggest changing it to:
"The `dns_canonicalize_hostname` flag in the krb5.conf configuration
file is now supported by the JDK Kerberos implementation."
Also, you should probably spell out "FQDN".
--Sean
On 10/8/18 2:19 PM, Roger Riggs wrote:
Hi Max,
The r
On 10/9/18 4:04 PM, Nico Williams wrote:
In order to file a bug or post a patch, you need to be an author
first. Read here:http://openjdk.java.net/projects/#project-author.
So it seems I need to send email to the project lead for... security?
And per-the census that would be Sean Mullan. No
On 10/10/18 6:23 AM, Severin Gehwolf wrote:
Hi,
What is the rationale of using DSA keys (2048 bit) as default for
genkeypair command?
http://hg.openjdk.java.net/jdk/jdk/file/c4a39588a075/src/java.base/share/classes/sun/security/tools/keytool/Main.java#l1120
There is really no other reason othe
On 10/10/18 8:06 AM, Alan Bateman wrote:
On 09/10/2018 21:55, Nico Williams wrote:
On Tue, Oct 09, 2018 at 04:31:07PM -0400, Sean Mullan wrote:
On 10/9/18 4:04 PM, Nico Williams wrote:
In order to file a bug or post a patch, you need to be an author
first. Read here:http://openjdk.java.net
Looks good to me.
--Sean
On 10/9/18 8:21 PM, Weijun Wang wrote:
Please review the fix at
http://cr.openjdk.java.net/~weijun/8211969/webrev.00/
The wrong path was never noticed because we ignore missing files. Now that we
only look for the open one and it should always be there, we will n
Please review this trivial fix to correct a couple of broken hyperlinks:
diff --git
a/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java
b/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java
--- a/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Re
On 10/10/18 4:52 PM, Michael StJohns wrote:
There is really no other reason other than DSA keys have been the
default keypairs generated by keytool for a long time, so there are
some compatibility issues we would have to think through before
changing it to another algorithm such as RSA. Weijun
t.
Except from forcing DSA users to add a -keyalg option, RSA and EC
users will not gain anything.
--Max
On Oct 11, 2018, at 5:05 AM, Anthony Scarpino
wrote:
On 10/10/2018 07:42 AM, Weijun Wang wrote:
On Oct 10, 2018, at 7:59 PM, Sean Mullan
wrote:
There is really no other reason othe
I think if we all really think we are better off in the long run not
having defaults, we probably want to do this over 2 releases and give an
advance warning that the change is coming. In JDK 12, we could emit a
warning, ex:
$ keytool -genkeypair ...
Warning: the default keypair alg (DSA) is a
On 10/12/18 10:33 AM, Langer, Christoph wrote:
Sean, what is your take on this?
Sorry, I haven't had time to look at this in more detail yet. But, let's
take a step back first. Can you or Matthias explain in more detail why
this fix is necessary? What are the use cases and motivation? The bug
Please review this change to copy the normative parts of the Java XML
Digital Signature API Specification into the java.xml.crypto module
javadocs and update relevant links in the javadocs. The Java XML Digital
Signature API Specification was published as part of JSR 105 and was
previously incl
iewer?
Thanks,
Sean
Thanks
Max
On Oct 16, 2018, at 1:59 AM, Sean Mullan wrote:
Please review this change to copy the normative parts of the Java XML Digital
Signature API Specification into the java.xml.crypto module javadocs and update
relevant links in the javadocs. The Java XML Digital Si
Please review this change to remove the GTE CyberTrust Global Root from
the cacerts keystore. This root is expired and all certificates that
chain back to this root have expired.
Note that retaining roots past their expiration date may make sense in
some cases. For example, if we removed a roo
The copyrights should be updated. Otherwise, looks good.
--Sean
On 10/17/18 4:45 PM, Adam Petcher wrote:
Webrev: http://cr.openjdk.java.net/~apetcher/8205476/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8205476
CSR: https://bugs.openjdk.java.net/browse/JDK-8212051
Please review the
Looks fine to me. It is unusual to have two noreg labels on a bug. Is
that acceptable? I would probably choose one or the other. noreg-hard
seems more appropriate to me.
--Sean
On 10/15/18 9:34 PM, Weijun Wang wrote:
Please take a review at
http://cr.openjdk.java.net/~weijun/8212216/webr
Please review this change to add the TLS anonymous and NULL cipher
suites to the "jdk.tls.disabledAlgorithms" security property.
These suites are used rarely and have security weaknesses. Anonymous
suites are vulnerable to man-in-the-middle attacks. NULL suites do not
provide confidentiality.
IMHO, this is kind of an odd thing to include in the javadocs, the fact
that it passed a bunch of tests. I'd be more inclined to simply remove
this sentence and (maybe) instead include it in the JDK Providers Guide,
but even then I am not sure it is really necessary.
--Sean
On 10/23/18 10:27
9
*/
Thanks
Max
On Oct 25, 2018, at 1:54 AM, Sean Mullan <mailto:sean.mul...@oracle.com>> wrote:
IMHO, this is kind of an odd thing to include in the javadocs, the
fact that it passed a bunch of tests. I'd be more inclined to simply
remove this sentence and (maybe) instead i
I get a "Page Not Found" error for
https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/documents/drbg/drbgtestvectors.zip
This works:
https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/drbg/drbgtestvectors.zip
--Sean
On 10/25/1
On 10/26/18 9:43 AM, Weijun Wang wrote:
On Oct 26, 2018, at 8:17 PM, Sean Mullan wrote:
I get a "Page Not Found" error for
https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/documents/drbg/drbgtestvectors.zip
This works:
https://csrc.nist.gov/CSRC/medi
Please remove this change to remove the Certificate, Identity,
IdentityScope, and Signer APIs. These APIs were marked for removal in
Java SE 10. They have been deprecated since Java SE 1.2, and have long
been superseded by other security APIs. Several SecurityPermission
targets and one security
On 10/26/18 4:10 PM, Sean Mullan wrote:
Please remove this change to remove the Certificate, Identity,
Typo above -
s/remove this change/review this change/
Must be Friday ... ;)
--Sean
IdentityScope, and Signer APIs. These APIs were marked for removal in
Java SE 10. They have been
I think you should put braces around the conditional statements on lines
332, 357, & 359. It would read better and avoid accidental bugs.
Where does delegatedCred get used? It seems to be never set.
Otherwise looks fine. You will need to add a noreg label if you can't
write a test.
--Sean
O
Looks fine to me.
--Sean
On 10/30/18 2:58 PM, Rajan Halade wrote:
Please review this fix to update test certificates used in QuoVadis CA
tests.
Webrev: http://cr.openjdk.java.net/~rhalade/8207059/webrev.00/
Thanks,
Rajan
On 10/31/18 5:25 PM, Nico Williams wrote:
I think you should put braces around the conditional statements on lines
332, 357, & 359. It would read better and avoid accidental bugs.
Is that part of a published Java style?
(Personally, I dislike braces for single statement blocks. But we'll follo
On 11/1/18 4:19 AM, Weijun Wang wrote:
On Nov 1, 2018, at 5:25 AM, Nico Williams wrote:
Otherwise looks fine. You will need to add a noreg label if you can't write a
test.
Yes.
Not sure what that means.
https://openjdk.java.net/guide/changePlanning.html#noreg.
I'll add a noreg-hard d
Please review this javadoc-only change to the Cipher class. An @apiNote
has been added to each of the getInstance methods to recommend that the
full transformation be specified when creating a Cipher and to avoid
relying on the defaults. Also a link to the defaults used by the JDK
providers has
an be problematic and are not recommended. My preference would
be to put more wording like that in the security guides.
--Sean
Xuelei
On 11/1/2018 7:57 AM, Sean Mullan wrote:
Please review this javadoc-only change to the Cipher class. An
@apiNote has been added to each of the getInstance me
On 11/1/18 1:29 AM, dean.l...@oracle.com wrote:
On 10/31/18 9:39 PM, Bernd Eckenfels wrote:
http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html
In checkContext should the security manager be null checked first
instead
Some of the copyrights need to be updated to 2018.
All else looks good to me as I had reviewed an earlier version of this
before. We have talked about doing this for a while now, so I am finally
glad we and are able to pretty much eliminate one of the more common
SecurityManager related hot-sp
On 10/31/18 9:15 PM, Peter wrote:
Hello Dean & David,
Interesting reading. Is DomainCombiner still being considered for
deprecation?
There are no immediate plans to deprecate DomainCombiner, but we are
looking at the SecurityManager (SM) and all of its related APIs and
evaluating differen
On 10/31/18 11:52 AM, Chris Hegarty wrote:
Xuelei,
On 30/10/18 20:55, Xuelei Fan wrote:
Hi,
For the current HttpsURLConnection, there is not much security
parameters exposed in the public APIs. An application may need richer
information for the underlying TLS connections, for example the
n
On 11/1/18 3:21 PM, dean.l...@oracle.com wrote:
On 11/1/18 9:48 AM, Sean Mullan wrote:
On 11/1/18 1:29 AM, dean.l...@oracle.com wrote:
On 10/31/18 9:39 PM, Bernd Eckenfels wrote:
http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security
o:xuelei@oracle.com>> wrote:
On 11/1/2018 11:24 AM, Sean Mullan wrote:
On 10/31/18 11:52 AM, Chris Hegarty wrote:
Xuelei,
On 30/10/18 20:55, Xuelei Fan wrote:
Hi,
For the current HttpsURLConnection, there is not much security
parameters exposed in the public APIs. An applic
On 11/7/18 7:22 PM, Xuelei Fan wrote:
On 11/7/2018 1:30 PM, Sean Mullan wrote:
https://bugs.openjdk.java.net/browse/JDK-8213161
http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/
I didn't see a test for SecureCacheResponse - is it possible?
JDK does not have the refe
rmation like home directory user names, etc?
Once we understand if there are any security issues, then we can decide
if allowing that via a system property is acceptable or not, and if so
the security risks that we would have to document for that property.
Thanks,
Sean
Thanks, Matthias
://cr.openjdk.java.net/~xuelei/8212261/webrev.05/
Looks good.
--Sean
Thanks,
Xuelei
On 11/8/2018 7:03 AM, Sean Mullan wrote:
On 11/7/18 7:22 PM, Xuelei Fan wrote:
On 11/7/2018 1:30 PM, Sean Mullan wrote:
https://bugs.openjdk.java.net/browse/JDK-8213161
http://cr.openjdk.java.net/~xuelei
Looking good, a couple of comments/questions:
* src/java.base/share/classes/java/security/Security.java
The isJdkSecurityProperty method could return false positives, for
example there may be a non-JDK property starting with "security.". I was
thinking it would be better to put all the JDK pro
e between SE properties
and JDK properties.
Hmm, I was reviewing v7, and the name was changed in v8. I think
isJdkSecurityProperty method is a better name.
--Sean
--Max
On Nov 14, 2018, at 2:53 AM, Sean Mullan wrote:
* src/java.base/share/classes/java/security/Security.java
The isJdkSe
On 11/13/18 1:53 PM, Sean Mullan wrote:
* src/java.base/share/classes/sun/security/x509/X509CertImpl.java
158 // Event recording cache list
159 private List recordedCerts;
Shouldn't this be static? Otherwise each certificate would have it's own
instance and duplicates wo
The fix and the CSR look good. Please also add a release note.
--Sean
On 11/8/18 11:51 AM, Adam Petcher wrote:
Oops. And the JBS ticket: https://bugs.openjdk.java.net/browse/JDK-8213363
On 11/8/2018 11:43 AM, Adam Petcher wrote:
webrev: http://cr.openjdk.java.net/~apetcher/8213363/webrev.00/
For 12, I think we should also document the group names in the std. alg
names document so we have somewhere to point to for what names can be
specified, otherwise users will be guessing.
So I targeted this to 12: https://bugs.openjdk.java.net/browse/JDK-8210755
--Sean
On 11/11/18 8:08 PM, Wei
On 11/14/18 5:07 AM, Weijun Wang wrote:
The CSR is re-opened. It is now focusing on -keyalg only. Please take a review:
https://bugs.openjdk.java.net/browse/JDK-8212111
I think the CSR should also include an example of the informational text
showing what algs and size were used. Looks goo
This is a good opportunity to document the
javax.net.ssl.sessionCacheSize system property in the SSLSessionContext
API (and use the new @systemProperty tag) in an @implNote, for example:
/**
* Returns the size of the cache used for storing
* SSLSession objects grouped under this
v 15, 2018, at 9:19 AM, Weijun Wang wrote:
Thanks to Xuelei and Sean. I added your recommended words and proposed the CSR.
On Nov 15, 2018, at 6:16 AM, Sean Mullan wrote:
On 11/14/18 5:07 AM, Weijun Wang wrote:
The CSR is re-opened. It is now focusing on -keyalg only. Please take a review:
h
On 11/15/18 10:33 AM, Adam Petcher wrote:
Done[1]. Please take a look when you have a chance.
[1] https://bugs.openjdk.java.net/browse/JDK-8213946
Looks fine.
--Sean
On 11/14/2018 4:29 PM, Sean Mullan wrote:
The fix and the CSR look good. Please also add a release note.
--Sean
On 11/8
On 11/16/18 9:04 AM, Seán Coffey wrote:
That's a good example and point Max. How does this revision look ?
http://cr.openjdk.java.net/~coffeys/webrev.8210838.v2/webrev/
2832 * This implementation returns a String containing the
transformation
2833 * used by this Cipher, the Cipher
think it would be easier to do it now, it seems pretty simple and that
way there is no need to worry about it later.
--Sean
Thanks,
Xuelei
On 11/15/2018 11:55 AM, Sean Mullan wrote:
This is a good opportunity to document the
javax.net.ssl.sessionCacheSize system property in the
SSLSessionCo
Looks ok. If there are no disadvantages to using a StringBuilder, I
would probably do that, since you are creating 4-5 separate Strings in
the toString method.
--Sean
On 11/16/18 11:35 AM, Seán Coffey wrote:
On 16/11/18 16:16, Sean Mullan wrote:
On 11/16/18 9:04 AM, Seán Coffey wrote
k.java.net/~coffeys/jmc_screenshots/shared_selection_certificateId.png/Screenshot%20from%202018-11-16%2015%3a28%3a59.png
Regards,
Sean.
On 14/11/18 21:09, Seán Coffey wrote:
Hi Sean,
comments inline..
On 13/11/2018 18:53, Sean Mullan wrote:
Looking good, a couple of comments/questions:
* src/java.base/share/class
ready.
As we are already there, I also update the setSessionCacheSize() for
more clarification.
Please review both CSR and webrev:
https://bugs.openjdk.java.net/browse/JDK-8213577
http://cr.openjdk.java.net/~xuelei/8210985/webrev.02/
Thanks,
Xuelei
On 11/16/2018 8:19 AM, Sean Mullan wr
Looks good. Please file a follow-on issue to remove the defaults.
--Sean
On 11/16/18 9:35 AM, Weijun Wang wrote:
Please take a review at
https://cr.openjdk.java.net/~weijun/8212003/webrev.00/
Here, a warning is added when -keyalg is not specified, and some informational
text output that
On 11/16/18 3:19 PM, Xuelei Fan wrote:
Thanks for the review, Jmail & Sean.
New webrev:
http://cr.openjdk.java.net/~xuelei/8210985/webrev.03/
I will update CSR when we come to an agreement.
On 11/16/2018 11:33 AM, Sean Mullan wrote:
122 * @apiNote Both the session timeout
On 11/26/18 7:51 AM, Baesken, Matthias wrote:
Hello, since 18th / 19th November we notice an error in the jtreg test
security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java
(on all platforms, for example linux x86_64 ).
Has anyone else seen the issue, or is it j
On 11/26/18 8:44 AM, Baesken, Matthias wrote:
Hi Sean thanks for the info .
Strange that the bug https://bugs.openjdk.java.net/browse/JDK-8202651 is
from May , but we only see the issue since last week ?!
It was marked Confidential for some reason, possibly by accident because
these
Looks good.
--Sean
On 11/22/18 8:12 AM, Weijun Wang wrote:
Please take a review at
https://cr.openjdk.java.net/~weijun/8214100/webrev.00/
Some exception handling codes are added to keytool when the keystore type does
not support probing.
Thanks
Max
o fix this soon.
--Sean
Best regards, Matthias
-Original Message-----
From: Sean Mullan
Sent: Montag, 26. November 2018 15:57
To: Baesken, Matthias ; security-
d...@openjdk.java.net
Cc: Lindenmaier, Goetz
Subject: Re: jdk11u and jdk/jdk : jtreg test error in
security/infra/java/sec
Looks fine to me.
--Sean
On 11/26/18 4:38 PM, joe darcy wrote:
Hello,
Please review a simple doc-only change to address:
JDK-8213911: Use example.com in java.net and other examples
http://cr.openjdk.java.net/~darcy/8213911.0/
Patch below.
Thanks,
-Joe
--- old/src/java.base/shar
.04/
Thanks,
Xuelei
On 11/19/2018 7:39 AM, Sean Mullan wrote:
On 11/16/18 3:19 PM, Xuelei Fan wrote:
Thanks for the review, Jmail & Sean.
New webrev:
http://cr.openjdk.java.net/~xuelei/8210985/webrev.03/
I will update CSR when we come to an agreement.
On 11/16/2018 11:33 AM, Sean Mu
Please review this change to remove TLS v1 and v1.1 from the SE required
algorithms for SSLContext. These TLS protocols have various weaknesses
and are no longer recommended and are being phased out, and thus should
be removed as requirements.
CSR: https://bugs.openjdk.java.net/browse/JDK-8214
Just a nit:
77 throw new IOException("DNSNames with blank components are
not permitted");
79 throw new IOException("DNSNames may not begin or end with
a .");
Use the singular "DNSName" to be consistent with the other exception
messages.
--Sean
On 11/23/18 11:45 AM,
On 11/26/18 8:30 PM, Weijun Wang wrote:
Ping
On Nov 21, 2018, at 9:56 PM, Weijun Wang wrote:
Please take a review at
https://cr.openjdk.java.net/~weijun/8214179/webrev.00/
Before this change, `keytool -genkeypair -keyalg EC -groupname brainpoolP256r1`
shows
Generating -1 bit EC key pa
801 - 900 of 2385 matches
Mail list logo
