The bug needs a noreg-cleanup label. Also, I would change the title to
"Remove unused DefaultHostNameVerifier".
Looks fine otherwise.
--Sean
On 7/25/17 1:47 PM, Xuelei Fan wrote:
Hi,
Please review a code cleanup update:
https://bugs.openjdk.java.net/browse/JDK-6645409
The sun.net.www.p
On 8/4/17 11:12 AM, Alan Bateman wrote:
On 04/08/2017 07:59, Jiri Vanek wrote:
Hello!
I'm packaging openjdk9 for Fedora, and following files:
jdk/lib/security/blacklisted.certs
jdk/lib/security/default.policy
Seems to be config files. Still, they are in lib/security, whether all
other con
I don't think we should warn at all if the keysize cannot be determined
or is inaccessible. The corresponding algorithm constraints checks don't
restrict keys whose size cannot be determined, so keytool and jarsigner
should be consistent.
--Sean
On 8/8/17 1:49 AM, Weijun Wang wrote:
Please r
Ok, I got it now. The method name "withWeak" threw me off a bit.
Fix looks good to me.
--Sean
On 8/8/17 9:00 AM, Weijun Wang wrote:
On Aug 8, 2017, at 8:22 PM, Sean Mullan wrote:
I don't think we should warn at all if the keysize cannot be
determined or is inaccessible. Th
Max,
Could you please review the following CSR:
https://bugs.openjdk.java.net/browse/JDK-8186047
Thanks,
Sean
On 8/9/17 8:02 PM, Weijun Wang wrote:
Looks fine. Should the specification part be formatted with and fixed
fonts?
Fixed. Can you add your name as Reviewer (you need to edit the CSR and
add your name to the "Reviewed By" box).
Thanks,
Sean
Thanks
Max
On Aug 10, 2017, at 3:1
column displays the certificate identifiers, which is a
combination of key algorithm, digest algorithm, key size and
expired mark (if any).
9. The test summary also be updated accordingly.
Best regards,
John Jiang
On 07/06/2017 23:11, Sean Mullan wrote:
On 6/6/17 9:14 PM, sha.ji...@oracle.com wrote:
017, at 3:15 AM, Sean Mullan wrote:
Max,
Could you please review the following CSR:
https://bugs.openjdk.java.net/browse/JDK-8186047
Thanks,
Sean
Please review this JDK 10 change to remove the deprecated classes in
com.sun.security.auth.** that have been previously marked with
forRemoval=true in JDK 9.
webrev: http://cr.openjdk.java.net/~mullan/webrevs/8159544/
I have also copied Jan for reviewing a change in langtools, and also
build-
s
Max
On Aug 18, 2017, at 3:08 AM, Sean Mullan wrote:
Please review this JDK 10 change to remove the deprecated classes in
com.sun.security.auth.** that have been previously marked with forRemoval=true
in JDK 9.
webrev: http://cr.openjdk.java.net/~mullan/webrevs/8159544/
I have also copied Ja
ebrev.01/
--Sean
Thanks,
Jan
On 17.8.2017 21:08, Sean Mullan wrote:
Please review this JDK 10 change to remove the deprecated classes in
com.sun.security.auth.** that have been previously marked with
forRemoval=true in JDK 9.
webrev: http://cr.openjdk.java.net/~mullan/webrevs/8159544/
I
On 8/31/17 4:49 AM, Weijun Wang wrote:
/**
* This package contains the {@link jdk.security.jarsigner.JarSigner} API,
* which backs the signing function of the {@code jarsigner} tool.
*/
I think you should say something about that this API can be used to sign
JAR files. The fact that it is als
The jdk changes look fine to me.
--Sean
On 9/6/17 12:17 AM, Weijun Wang wrote:
Hi All
Please review the change, which spans to root, jdk and langtools repos.
http://cr.openjdk.java.net/~weijun/8148371/
I've searched for the "policytool" word in the whole jdk10/jdk10 forests,
removed all
implementation of the SASL
* GSSAPI mechanism.
Thanks
Max
On Aug 31, 2017, at 11:10 PM, Sean Mullan wrote:
On 8/31/17 4:49 AM, Weijun Wang wrote:
/**
* This package contains the {@link jdk.security.jarsigner.JarSigner} API,
* which backs the signing function of the {@code jarsigner} tool.
*/
I think
Cross-posting to security-dev as this is more relevant to that list and
bcc-ing core-libs-dev.
I think this might be an issue with the JavaWebStart SecurityManager not
being granted the proper permissions. It is possible that the deployment
policy files are not being loaded or there is some ot
'll have to print it and go through an approval process
to show it to you via a scanned pdf. I will continue testing of our app
with the security debug turned on so that I'll have the output if it
happens again. I also have the logging and tracing enabled in the java
contro
Cross-posting to core-libs-dev as this proposal is really more
appropriate for review on that list.
--Sean
On 10/3/17 1:48 AM, Philipp Kunz wrote:
Hi
This has not been asked for and there is also no bug yet but
nevertheless let me propose to change Attributes.map to specific generic
types.
Hi Phillip,
All of these bugs are in the core-libs area, so I am copying the
core-libs-dev list since that is where they should be discussed and
reviewed. I have -bcc-ed security-dev (where this was originally posted).
--Sean
On 10/2/17 1:24 PM, Philipp Kunz wrote:
Hi,
While fixing JDK-669
Looks good to me. Please add a release note subtask to the issue.
--Sean
On 10/19/17 11:56 PM, Weijun Wang wrote:
Please review this patch. A CSR [1] is also filed.
diff --git a/src/java.base/share/classes/javax/security/auth/Policy.java
b/src/java.base/share/classes/javax/security/auth/Polic
- test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
65 * @bug 6543842 6543440 6939248 8009636 8024302 8163304 8169911
8166222 8180289
should not include 8166222
346 // 8166222: unvalidated TSA cert chain
347 sign("tsnoca")
348
Looks good.
--Sean
On 10/27/17 2:54 AM, Weijun Wang wrote:
Turns out there is a javac warning for "removal". Please review again at
http://cr.openjdk.java.net/~weijun/8159535/webrev.00
Thanks
Max
On Oct 20, 2017, at 11:56 AM, Weijun Wang wrote:
Please review this patch. A CSR [1] is a
Please review this JDK 10 change to mark the deprecated
java.security.{Certificate,Identity,IdentityScope,Signer} APIs with
forRemoval=true. These APIs will be removed from a subsequent version of
Java SE. They have been deprecated since 1.2 and superseded by
java.security.cert, java.security.K
Please review this JDK 10 change to mark the deprecated
java.security.acl APIs with forRemoval=true. These APIs will be removed
from a subsequent version of Java SE. They have been deprecated since
JDK 9 and superseded by classes in java.security since 1.2. It is no
longer necessary to retain t
Fix looks good. Do you also need to add a label or subtask to the bug so
that the localization team knows that they still need to fix the
resource files?
--Sean
On 11/13/17 11:20 PM, Weijun Wang wrote:
keytool contains a printf("%d-bit %s key", 1024, "RSA") call but when
it's translated into
On 11/8/17 6:47 PM, Valerie Peng wrote:
Hi, Sean,
I updated the webrev in place - now this change contains only javadoc
update of DSAKeyPairGenerator interface.
CSR has also been updated accordingly. Could you please take a look?
Sure.
35 * DSAKeyPairGenerator, each provider must supply
Thanks for the feedback.
I have updated webrev to address your comments:
http://cr.openjdk.java.net/~valeriep/8182484/webrev.01/
CSR has also been updated and proposed.
Valerie
On 11/14/2017 10:47 AM, Sean Mullan wrote:
On 11/8/17 6:47 PM, Valerie Peng wrote:
Hi, Sean,
I updated the webrev in p
Please review a new JEP Draft titled "Open-Source the Root
Certificates". The JDK source code currently contains an empty cacerts
keystore, which prevents security components such as TLS from working
out-of-the-box on OpenJDK builds.
The goal of this JEP is to provide a default set of root cer
Please review this change to remove the pre-JDK 1.2 SecurityManager
methods that have been deprecated since JDK 1.2 and marked for removal
in JDK 9. These methods are fragile, error-prone and have been obsolete
since the SecurityManager was revamped in JDK 1.2. The methods to be
removed are: ge
On 11/22/17 9:59 AM, Alan Bateman wrote:
http://cr.openjdk.java.net/~mullan/webrevs/8186535/webrev.00/
This mostly looks good.
Does the stack walker created in AppletSecurity need to be done in a
privileged block? If this is just the mouldy appletviewer tool then
ignore my comment.
Hmm. Wh
On 11/28/17 2:41 PM, mandy chung wrote:
On 11/22/17 6:37 AM, Sean Mullan wrote:
Please review this change to remove the pre-JDK 1.2 SecurityManager
methods that have been deprecated since JDK 1.2 and marked for removal
in JDK 9. These methods are fragile, error-prone and have been
obsolete
On 12/1/17 12:22 PM, Alan Bateman wrote:
On 01/12/2017 17:16, Volker Simonis wrote:
Hi Rajan,
great to see this finally happen!
I have just a quick question related to the tests. As far as I can
see, the tests will only succeed if the OpenJDK will be build with the
new open sourced, Oracle r
This fix looks good to me.
Thanks,
Sean
On 12/1/17 11:54 AM, Rajan Halade wrote:
May I request for your review of this fix to open source the root
certificates in Oracle's Java SE Root CA program. The fix is to populate
cacerts keystore with root certificates and add corresponding tests for
i
On 12/1/17 2:25 PM, Rajan Halade wrote:
On 12/1/17 10:09 AM, Sean Mullan wrote:
So only the VerifyCACerts test would potentially fail by default (it
is part of tier2). If this becomes a big issue, we can follow-up later
and investigate more with some sort of fix, but I don't think this
s
On 12/1/17 2:12 PM, Rajan Halade wrote:
Thanks for your reviews. I have updated webrev -
http://cr.openjdk.java.net/~rhalade/8189131/webrev.01/
I realized an error in my script which missed 7 new root certs listed in
JEP, these are added now. Update also includes some code enhancements
in Ve
Looks good, but can you add some additional comments explaining why the
sizes need to be identical and why sometimes they can be different?
--Sean
On 11/30/17 10:26 PM, Weijun Wang wrote:
Please review the fix. The comment said the test will try several times but
when ts2.cert does not have t
On 12/5/17 12:01 PM, Volker Simonis wrote:
Hi Rajan,
'cacerts' is a binary file and I thought we have at least the
convention in the OpenJDK project that we don't want to check in
binary artefact's if possible.
One problem with 'cacerts' being a binary file is that we can not add
a license and
On 12/5/17 9:27 AM, Seán Coffey wrote:
Looking to improve the stacktrace output made when debug mode is enabled
for java.security and sun.security classes. In the past, some of these
have led to confusion for end users. Best to add some context when we're
printing stacktrace for informational,
When signing, I think we should always print when the timestamp will
expire, even if it is 10 years from now. For the warning, I would bump
it up 6 months to a year. (It could potentially be more than this - a
fresh timestamp ideally should be good for > 5 years in my opinion).
Perhaps we don't
Update the copyright date on KeyStoreUtil.java. Otherwise looks fine to me.
--Sean
On 12/7/17 3:53 AM, Weijun Wang wrote:
Hi All
Please take a look at
http://cr.openjdk.java.net/~weijun/8192987/webrev.00/
The fix delays the assignment of storetype and srcstoretype (when they are not
pro
Can you keep line 48, which was just a javadoc wording fix? Otherwise,
looks ok. Please re-open or file new bugs for JDK-8058547 and JDK-8055753.
Thanks,
Sean
On 12/6/17 8:35 PM, Ivan Gerasimov wrote:
Hello!
A regression caused by the recent fixes of the ProtectionDomain cache
was observed.
t; but should not be removed. Although we can probe storetype of pkcs12/jks/jceks, that
doesn't mean we can probe a 3rd party storetype.
The test is updated so that when a wrong storetype is provided, it will be used
and the loading of keystore would fail.
Thanks
Max
On Dec 7, 2017, at 9:
It looks like you converted p12importks.sh from shell code to java in
JKStoPKCS12.java, right? I think you should still include 8010125 in the
@bug label in JKStoPKCS12.java though.
Otherwise, looks good, one question though:
If you are converting a JKS keystore to a PKCS12 keystore using keyt
Looks fine to me.
--Sean
On 12/13/17 1:02 PM, Ivan Gerasimov wrote:
Ping!
The patch is the anti-delta of the fixes, so we're just reverting to
what we used to have prior these fixes.
Would you please help review this and approve the backport?
With kind regards,
Ivan
On 12/11/17 9:30 AM,
at 5:01 AM, Sean Mullan wrote:
When signing, I think we should always print when the timestamp will expire, even
if it is 10 years from now. For the warning, I would bump it up 6 months to a
year. (It could potentially be more than this - a fresh timestamp ideally should
be good for > 5 years
This looks good. Just a few comments:
- please add a release note subtask and open a separate docs issue to
document the new etypes
- does this need a CSR? I would think it does because it is adding
support for a new RFC and etypes
* AesSha2DkCrypto.java
- why does stringToKey(char[] passwor
On 12/19/17 10:52 AM, Weijun Wang wrote:
* AesSha2DkCrypto.java
- why does stringToKey(char[] password, String salt, byte[] s2kparams) swallow
exceptions but stringToKey(char[] secret, byte[] salt, byte[] params) does not?
I simply copy the behavior of the same methods for other etypes. Looks
On 12/20/17 8:29 PM, Weijun Wang wrote:
Please take a review at
https://bugs.openjdk.java.net/browse/JDK-8193916
Looks good to me.
I'm thinking about file an issue https://github.com/javaee/glassfish/issues
requesting for the removal of javax.security.auth.Policy-related code. Is that
On 12/19/17 8:39 PM, Weijun Wang wrote:
On Dec 20, 2017, at 5:02 AM, Sean Mullan wrote:
On 12/19/17 10:52 AM, Weijun Wang wrote:
* AesSha2DkCrypto.java
- why does stringToKey(char[] password, String salt, byte[] s2kparams) swallow
exceptions but stringToKey(char[] secret, byte[] salt
On 1/10/18 11:44 PM, Weijun Wang wrote:
The class spec of SignedObject.java [1] contains:
* {@code
* Signature signingEngine = Signature.getInstance(algorithm,
* provider);
* SignedObject so = new SignedObject(myobject, signingKey,
*
On 1/9/18 8:40 PM, Weijun Wang wrote:
The code can also throw GeneralSecurityException but those are also always
suppressed because of the catch block. Is that the right behavior?
Not a right behavior but should be harmless here. In my understanding, in the
case of PBE, as long the passphrase
Looks good.
--Sean
On 1/15/18 8:57 PM, Weijun Wang wrote:
The translation team suggested a small text change:
diff --git
a/src/java.base/share/classes/sun/security/tools/keytool/Resources.java
b/src/java.base/share/classes/sun/security/tools/keytool/Resources.java
--- a/src/java.base/share/c
an 13, 2018, at 3:52 AM, Sean Mullan wrote:
On 1/9/18 8:40 PM, Weijun Wang wrote:
The code can also throw GeneralSecurityException but those are also always
suppressed because of the catch block. Is that the right behavior?
Not a right behavior but should be harmless here. In my understanding, i
Hi Leo,
Thanks for the offer to help and contribute! I would suggest you start
by reading the OpenJDK contribution page (if you have not done so already):
http://openjdk.java.net/contribute/
which has some tips and other helpful advice. You will also need to sign
an OCA (Oracle Contributor A
Please review this tck-red bug that needs to be fixed in JDK 10.
bug: https://bugs.openjdk.java.net/browse/JDK-8194307
webrev: http://cr.openjdk.java.net/~mullan/webrevs/8194307/webrev.00/
The current fix is slightly limited in that it doesn't allow the
LoadStoreParameter to be passed onto the
, ProtectionParameter)
instead of getInstance(File, LoadStoreParameter) and that would have
been more appropriate and sufficient, as it would have still allowed a
user to use a CallbackHandler to provide a password, which can be useful.
--Sean
Thanks
Max
On Jan 18, 2018, at 6:36 AM, Sean
I believe sunrsasign.jar was removed in JDK 1.5. So it seems like the
line below is no longer necessary and should be removed. I have copied
hotspot-dev to see if this is a known issue or if I am missing something.
--Sean
On 1/19/18 1:28 PM, Bernd wrote:
Hello,
I noticed that when I strace a
Hi Fotis,
This is an interesting issue and I agree it is important. From your post
it seems that each implementation has come up with a different mechanism
for solving this problem, which is unfortunate - it would be more ideal
if we could converge on a standard mechanism for addressing it. Th
Looks fine to me.
--Sean
On 1/24/18 10:53 PM, Weijun Wang wrote:
Please take a review at
http://cr.openjdk.java.net/~weijun/8177398/webrev.00/
Dotfiles will not be included in "includedir" of krb5.conf.
Thanks
Max
On 1/24/18 5:39 AM, Fotis Loukos wrote:
You may not be aware, but the JDK does currently support a mechanism for
blacklisting certificates. The lib/security/blacklisted.certs file
contains a list of the fingerprints of certificates that are explicitly
distrusted. If a root was compromised and add
Does Runtime.version().feature() return the same value as the
"java.specification.version" property? (see
sun.security.util.SecurityConstants.PROVIDER_VER).
That is the value that the JDK security providers use as their version.
If not, this test may fail when we bump up the version to 11 and
On 1/30/18 1:19 PM, joe darcy wrote:
Hi Sean,
On 1/30/2018 10:03 AM, Sean Mullan wrote:
Does Runtime.version().feature() return the same value as the
"java.specification.version" property? (see
sun.security.util.SecurityConstants.PROVIDER_VER).
That is the value that the JD
On 1/24/18 5:36 AM, Patrick Goovaerts wrote:
Hi,
After updating JKD 1.8.0 from u112 to u121, i get errors executing
webservices which uses a certificate.
The error I get is:
com.sun.xml.internal.ws.wsdl.parser.InaccessibleWSDLException: 2 counts
of InaccessibleWSDLException
In the exampl
Looks good.
--Sean
On 2/5/18 2:26 PM, Adam Petcher wrote:
Please review the following change:
JBS: https://bugs.openjdk.java.net/browse/JDK-8194251
Webrev: http://cr.openjdk.java.net/~apetcher/8194251/webrev.00/
We ran into a problem related to loading locale data when a security
policy file
Looks good.
--Sean
On 2/6/18 4:39 AM, Weijun Wang wrote:
Please review the following
JBS: https://bugs.openjdk.java.net/browse/JDK-8196823
CSR: https://bugs.openjdk.java.net/browse/JDK-8196845
Fix: http://cr.openjdk.java.net/~weijun/8196823/webrev.00/
Some note:
1. I copied the spec
This looks fine although I don't really think you need the othervm on
line 36; that seems like something that is done separately as part of
testing all of the tests on different locales.
--Sean
On 2/7/18 11:19 AM, Adam Petcher wrote:
Webrev: http://cr.openjdk.java.net/~apetcher/8196215/webrev
On 2/7/18 2:26 PM, Adam Petcher wrote:
On 2/7/2018 12:33 PM, Sean Mullan wrote:
This looks fine although I don't really think you need the othervm on
line 36; that seems like something that is done separately as part of
testing all of the tests on different locales.
I included that li
Just a few comments:
- Update copyrights to include 2018
- I think you should also open a jarsigner docs issue to add new
warnings for expired TSA and expiring signer and TSA certs
* Main.java
l1740, typo: s/singer/signer/
--Sean
On 2/9/18 4:10 AM, Weijun Wang wrote:
Updated again at http
In the related CSR, you should also list the system/security properties
that were only used with javax.security.auth.Policy and therefore are no
longer necessary:
1. auth.policy.provider
2. cache.auth.policy (seems to have never been documented but I found a
reference to it in some old IBM jav
On 3/4/18 10:44 PM, Weijun Wang wrote:
For the 3rd/4th ones above, there is still some code in
sun.security.provider.PolicyFile that looks for it, so it can be removed as
part of this change now. Can you remove that and send an updated webrev?
http://cr.openjdk.java.net/~weijun/8191139/webrev.
I haven't reviewed all of it (mainly just the standard classes), but
here are some comments so far:
- General comments
For new public classes, you don't need to start the sentence with the
name of the class since that is implied and will show up in javadoc
pages. For example, "XECKey is an in
On 3/12/18 4:39 AM, Weijun Wang wrote:
I put "SHA-1" in a DisabledAlgorithmConstraints, it rejects SHA1 but allows
sha1.
That sounds like a bug.
The reason is that
http://hg.openjdk.java.net/jdk/jdk/file/6b54e8cd9b3d/jdk/src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.jav
curity-dev on behalf
of Sean Mullan
*Sent:* Monday, March 12, 2018 3:41:36 PM
*To:* Weijun Wang; security-dev@openjdk.java.net
*Subject:* Re: Algorithm aliases of SHA-1 in DisabledAlgorithmConstraints
On 3/12/18 4:39 AM, Weijun Wang wrote:
I put "SHA-1" in a DisabledAlgorithmConstraint
On 3/9/18 8:25 AM, Adam Petcher wrote:
New webrev: http://cr.openjdk.java.net/~apetcher/8171277/webrev.01/
I think somewhere there should be a sentence or two on the difference
between XECKeys and ECKeys and when you would want to use each. This
is important enough that I think some detail s
On 3/13/18 1:06 AM, Weijun Wang wrote:
On Mar 12, 2018, at 10:41 PM, Sean Mullan wrote:
I would tend to think that we should only specify (or guarantee) that standard
names are checked and used in the disabled algorithm properties.
But this means first we must only set standard names in
, I'm ok if you don't do this now - we can
always do it later.
--Sean
On 3/12/18 3:03 PM, Sean Mullan wrote:
On 3/9/18 8:25 AM, Adam Petcher wrote:
New webrev: http://cr.openjdk.java.net/~apetcher/8171277/webrev.01/
I think somewhere there should be a sentence or two on the
Looks ok to me.
--Sean
On 3/12/18 2:42 AM, Weijun Wang wrote:
Please take a review at
http://cr.openjdk.java.net/~weijun/8186228/webrev.00/
Even a timeout of 30 seconds could happen, maybe because the UDP packet is
lost. The change covers all possible output where each request has 3 chan
On 3/22/18 11:08 AM, Xuelei Fan wrote:
This draft JEP contains a proposal to extend the SunJSSE provider to
support the Transport Layer Security (TLS) Protocol Version 1.3 [1].
For more details, please see:
https://bugs.openjdk.java.net/browse/JDK-8145252
See also http://openjdk.java.net/jep
Please remove this change to remove several SecurityManager methods that
have been marked for removal since Java SE 9: checkTopLevelWindow,
checkSystemClipboardAccess, checkAwtEventQueueAccess, and
checkMemberAccess. These methods no longer have any benefit, and
removing them will follow throug
On 3/27/18 11:26 AM, Alan Bateman wrote:
On 27/03/2018 16:15, Sean Mullan wrote:
Please remove this change to remove several SecurityManager methods
that have been marked for removal since Java SE 9:
checkTopLevelWindow, checkSystemClipboardAccess,
checkAwtEventQueueAccess, and
I also made a similar change to the Risks and Assumptions section of the
JEP.
--Sean
On 3/28/18 3:47 PM, Bradford Wetmore wrote:
On 3/28/2018 11:46 AM, R Wagner wrote:
I was wondering if it was possible to update this issue and make a
comment that TLS 1.3 has been formally adopted.
I just
Looks fine to me.
--Sean
On 3/23/18 12:58 PM, Ivan Gerasimov wrote:
Ping.
Can I please have a review for this test fix?
Thanks in advance!
Ivan
On 3/6/18 1:01 PM, Ivan Gerasimov wrote:
Hello!
The regression test SignatureLength.java was seen to fail on some
Solaris systems.
This is be
Copying Naoto.
Naoto, the regression mentioned below that is causing the NPE looks to
be caused by changes to java.util.ResourceBundle in
https://bugs.openjdk.java.net/browse/JDK-8182601
Can you take a look and file a bug, if so?
Thanks,
Sean
On 3/29/18 4:53 AM, Peter wrote:
Hello Java sec
A few comments so far; have not finished my review yet.
General comment:
Many of these tests test more than XDH. That is fine and good for
increasing coverage, but have you looked through existing tests to see
if you are duplicating anything we are already testing and maybe those
tests could
The updated webrev looks good.
--Sean
On 3/27/18 4:23 PM, Adam Petcher wrote:
After the last code review[1] on this topic completed, it was suggested
that I add some more "spec enforcement" to the XDH service. The code
hasn't been integrated yet, so I'm doing this as a follow-on review
under
Looks fine to me.
--Sean
On 3/30/18 2:29 AM, Prasadrao Koppula wrote:
Hi,
Can I please have a review for this fix?
Thanks,
Prasad.K
*From:* Prasadrao Koppula
*Sent:* Tuesday, March 20, 2018 3:46 PM
*To:* security-dev@openjdk.java.net
*Subject:* [11] RFR: 8187218: GSSCredential.getRemainingLi
I think you should use a 2048-bit DSA key instead of 1024-bit.
Otherwise looks fine.
--Sean
On 4/3/18 4:12 PM, Amanda Jiang wrote:
Hi All,
The changeset below updates an expired alias in keystore. Please help to
review it.
Bug: https://bugs.openjdk.java.net/browse/JDK-8190333
Webrev: http:
On 3/30/18 12:48 PM, David Lloyd wrote:
Is it possible that this could make Java 11, or is that a long shot?
We cannot say that it will make JDK 11 at this time. Also, at this stage
in the JEP 2.0 Process, a Candidate means that it "is merely an idea
worthy of consideration by JDK Release Pro
Comments below ...
On 4/2/18 4:07 AM, Sibabrata Sahoo wrote:
Hi Sean,
My comments In-lined..
Thanks,
Siba
-Original Message-
From: Sean Mullan
Sent: Saturday, March 31, 2018 12:13 AM
To: Sibabrata Sahoo ; Adam Petcher
; security-dev@openjdk.java.net
Subject: Re: RFR: 8200219
The 2 space indentation in some of the methods of OutputAnalyzer.java is
unconventional. I would fix those methods to use 4 spaces. Looks fine
otherwise.
--Sean
On 4/4/18 4:38 AM, bhanu.prakash.gopula...@oracle.com wrote:
Hi All,
Please review fix for following issue:
JBS bug: https://bugs
On 4/9/18 11:39 PM, Xuelei Fan wrote:
I may use a title/subject that states the new state or behavior changes
of a RFE. For example, "Uses UTF-8 for KerberosString". Otherwise,
looks fine to me.
The title should be more specific that KerberosString uses UTF-8. I
suggest: "KerberosString use
On 4/9/18 10:13 AM, Sibabrata Sahoo wrote:
Here is the new patch addressing all comments.
Webrev:http://cr.openjdk.java.net/~ssahoo/8184359/webrev.01/
Changes includes:
1)
KeyAgreementTest.java
KeySizeTest.java
I have ensured no duplicate Test cases exist for the functionality provide
Please update copyright dates. Otherwise looks fine.
--Sean
On 4/12/18 1:24 PM, Claes Redestad wrote:
Hi,
ProtectionDomain creates both the JavaSecurityAccess and the
JavaSecurityProtectionDomainAccess SharedSecrets, and since 9 both are
always created eagerly during early bootstrap. It seem
288 System.err.println("WARNING: ");
I don't think you need to print a warning in this case since this
expired root is an exception to the policy. Also, once the cert has
expired, the subsequent message "will expire" doesn't make sense:
293 System.err.prin
On 4/13/18 11:46 AM, Rajan Halade wrote:
Thanks for your comments. Updated webrev is at
http://cr.openjdk.java.net/~rhalade/8198240/webrev.01/
Looks fine.
--Sean
On 4/13/18 3:25 PM, Bradford Wetmore wrote:
SunRsaSignEntries.java
--
145: Where did you come up with this convention for your aliases?
SHA1withRSA-PSS
I see Bouncy Castle[1] and Android[2] are both using:
SHA*withRSA/PSS
RSASSA-PSS (name from PKCS#1)
[1]
See http://openjdk.java.net/jeps/8199569 for a more readable form of the
JEP.
--Sean
On 4/17/18 12:30 PM, Weijun Wang wrote:
Hi All
Please take a look at https://bugs.openjdk.java.net/browse/JDK-8199569.
With the Windows 10 Credential Guard feature turned on, Java can no longer uses
the TGT
On 4/16/18 9:50 AM, Sibabrata Sahoo wrote:
Now there is only 1 Test file in the deleted list which has duplicate code. Due
to that I have pointed the older JBS bug ID JDK-4936763 in
KeyAgreementTest.java and linked the same to JDK-8184359 too.
Reverted the duplicate code merge in KeySizeTest.j
lei
On 4/16/2018 11:40 AM, Sean Mullan wrote:
On 4/13/18 3:25 PM, Bradford Wetmore wrote:
SunRsaSignEntries.java
--
145: Where did you come up with this convention for your aliases?
SHA1withRSA-PSS
I see Bouncy Castle[1] and Android[2] are both using:
SHA*withRSA
The ChaCha20ParameterSpec.java file should have an @since 11 annotation
on it.
--Sean
On 3/26/18 3:08 PM, Jamil Nimeh wrote:
Hello all,
This is a request for review for the ChaCha20 and ChaCha20-Poly1305
cipher implementations. Links to the webrev and the JEP which outlines
the characteris
--Sean
--Jamil
Original message ----
From: Sean Mullan
Date: 4/26/18 8:57 AM (GMT-08:00)
To: Jamil Nimeh , OpenJDK Dev list
Subject: Re: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
The ChaCha20ParameterSpec.java file should have an @since 11 annotation
on it.
1701 - 1800 of 2385 matches
Mail list logo
