Please review this fix, which removes the overloaded
sun.security.util.ObjectIdentifier.equals(ObjectIdentifier) method.
webrev: http://cr.openjdk.java.net/~juh/8022444/00/
bug: https://bugs.openjdk.java.net/browse/JDK-8022444
Thanks,
Jason
Please review this change, which adds support for two curves to XML
Signature.
webrev: http://cr.openjdk.java.net/~juh/8079693/00/
bug: https://bugs.openjdk.java.net/browse/JDK-8079693
Thanks,
Jason
Please review this fix, which enables parsing of X400Address-type
Subject Alternative Names.
webrev: http://cr.openjdk.java.net/~juh/8058543/00/
bug: https://bugs.openjdk.java.net/browse/JDK-8058543
Jason
Please review this change to deprecate the com.sun.jarsigner package.
webrev: http://cr.openjdk.java.net/~juh/8076535/00/
jbs: https://bugs.openjdk.java.net/browse/JDK-8076535
Thanks,
Jason
On 4/14/15 11:58 AM, Sean Mullan wrote:
On 04/13/2015 07:40 PM, Jason Uh wrote:
Thanks, Sean.
Here is a revision:
http://cr.openjdk.java.net/~juh/8076117/02/
Looks good. Just one other comment: the type field in Validator should
be private since it isn't referenced by any other code in
switch, make an Set checkedOids as
new parameter, so it is possible to tell what is already been checked.
That mean if the "non SimpleValidator" checks only part of the critical
extensions
the EndEntityChecker would still throw an Exception.
Gruß Thomas
On 10.04.2015 21:39, Jason Uh wrote:
Thanks, Sean.
Here is a revision:
http://cr.openjdk.java.net/~juh/8076117/02/
On 04/13/2015 12:59 PM, Sean Mullan wrote:
On 04/10/2015 07:18 PM, Jason Uh wrote:
Revised webrev: http://cr.openjdk.java.net/~juh/8076117/01/
Hi Jason,
Just a few comments:
* Validator
272: I would name this
xport an entire keystore as an encoded string. (Is there a way?)
Revised webrev: http://cr.openjdk.java.net/~juh/8076117/01/
Thanks,
Jason
Xuelei
On 4/11/2015 3:39 AM, Jason Uh wrote:
Please review this fix, which prevents redundant extension checking in
EndEntityChecker.
When checking exten
Please review this fix, which prevents redundant extension checking in
EndEntityChecker.
When checking extensions in an end entity certificate, if
sun.security.validator.EndEntityChecker comes across any extensions that
are critical and unknown, it throws an exception, even if those
extension
Hi Alexander,
I'm not an official Reviewer, but this change looks good to me.
Thanks,
Jason
On 4/8/15 4:37 AM, alexander stepanov wrote:
Hello,
could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8076223/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-807622
On 03/27/2015 03:53 AM, Wang Weijun wrote:
On Mar 27, 2015, at 06:37, Jason Uh wrote:
Please review this revision:
http://cr.openjdk.java.net/~juh/7145757/01/
* a global nameCache is maintained in OIDMap as suggested
Can you just use the existing OIDMap.getId() method? It looks like
Extensions does not have
getExtension() that returns null. Now that you create another inconsistence
that X509CRLImpl.getExtension() is starting to throw IOE while
X509CertImpl.getExtension() does not.
--Max
On Mar 19, 2015, at 07:40, Jason Uh wrote:
Hi Max,
On 03/18/2015 04:09 PM, Wang We
Please review this change to remove the "Reverse" CertPathBuilder mode,
which has never been supported and is undocumented.
webrev: http://cr.openjdk.java.net/~juh/7194452/00/
bug: https://bugs.openjdk.java.net/browse/JDK-7194452
Thanks,
Jason
tle odd that they weren't
being thrown, but they may not need to be there for CRLExtensions. I can
take them out.
--Max
On Mar 18, 2015, at 09:34, Jason Uh wrote:
Please review this fix, which changes the internal map in
sun.security.x509.CertificateExtensions and CRLExtensions to alway
Please review this change, which removes methods in internal net
packages that use the deprecated javax.security.cert.X509Certificate type.
webrev: http://cr.openjdk.java.net/~juh/8074531/00/
bug: https://bugs.openjdk.java.net/browse/JDK-8074531
Thanks,
Jason
Please review this fix, which changes the internal map in
sun.security.x509.CertificateExtensions and CRLExtensions to always use
the OID as the key.
As stated in the JBS issue:
The sun.security.x509.CertificateExtensions class maintains a Map map
field to store all the extensions it manages.
Hi Joe,
Looks good to me. There actually is already a bug for this:
https://bugs.openjdk.java.net/browse/JDK-8074673
Thanks for the fix,
Jason
On 3/9/15 5:56 PM, joe darcy wrote:
Hello,
When doing a JDK docs build, I noticed a javadoc warning is reported for
PKCS8EncodedKeySpec; the type i
While these methods are going to be removed soon anyway, @Deprecated
actually seems like the more appropriate choice because we do want to
discourage use of these methods, even if they are non-public APIs.
Here it is with that change; please take a look:
http://cr.openjdk.java.net/~juh/8073430/
also.
Thanks
Max
On Mar 5, 2015, at 03:02, Jason Uh wrote:
webrev: http://cr.openjdk.java.net/~juh/8073430/00/
jbs: https://bugs.openjdk.java.net/browse/JDK-8073430
Please review this change, which deprecates the classes in java.security.acl
and javax.security.cert. These packages have bee
webrev: http://cr.openjdk.java.net/~juh/8073430/00/
jbs: https://bugs.openjdk.java.net/browse/JDK-8073430
Please review this change, which deprecates the classes in
java.security.acl and javax.security.cert. These packages have been
superseded by replacements for a long time.
For java.securit
uggest that you push your changeset with both the 8054037 and
8055207 bug IDs then.
regards,
Sean.
On 02/03/2015 23:07, Jason Uh wrote:
Thanks for the comments, Sean; Vinnie, for the patch.
Here's an updated webrev with your suggested changes and Vinnie's patch.
http://cr.openjdk.java.n
uststore is empty. It's not
very obvious to the novice user!
I believe the output corresponds to :
jdk/src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java#498
We need to at least print "Empty cert chain" where applicable. This
belongs in jsse code but it would be great
Please review this fix, which removes the sun.security.acl package.
webrev: http://cr.openjdk.java.net/~juh/8072663/00/
jbs: http://bugs.openjdk.java.net/browse/JDK-8072663
The sun.security.acl package is the default implementation of
java.security.acl but it's not used in JDK. The JCK tests fo
Hi Max,
Not an official reviewer, but this looks good to me.
Jason
On 2/15/15 11:56 PM, Weijun Wang wrote:
Please review the fix at
http://cr.openjdk.java.net/~weijun/8073182/webrev.00/
This fix stores extensions inside CertificateExtensions using OID as key
so there will never be a type
- you can move line 215 inside the block starting at line 217.
* ECDSASignature.java
- lines 83-84 can be changed to this(false);
--Sean
On 02/11/2015 06:18 PM, Jason Uh wrote:
Please review this change, which enables DSA and ECDSA signatures in the
IEEE P1363 format (the concatenation of r and s
Please review this change, which augments some of the debug statements
for java.security.debug=certpath.
webrev: http://cr.openjdk.java.net/~juh/8054037/00/
bug: https://bugs.openjdk.java.net/browse/JDK-8054037
Thanks,
Jason
algorithm format.
// withand
+ // within
Pattern pattern =
- Pattern.compile("with|and", Pattern.CASE_INSENSITIVE);
+ Pattern.compile("with|and|in", Pattern.CASE_INSENSITIVE);
Thanks,
Xuelei
On 2/12/2015 7:18 AM, Jason Uh wrote:
Please review this change, w
Please review this change, which enables DSA and ECDSA signatures in the
IEEE P1363 format (the concatenation of r and s) by introducing new
algorithm name Strings.
http://cr.openjdk.java.net/~juh/8042967/02/
Thanks,
Jason
On 01/30/2015 02:18 PM, Jason Uh wrote:
Mike,
Thanks again for
Mike,
Thanks again for weighing in. As you're not opposed to the proposal, I
will go ahead and move forward with this plan.
I will put out an updated webrev with the new approach once it is ready.
Thanks,
Jason
On 1/29/15 3:56 PM, Michael StJohns wrote:
At 03:41 PM 1/29/2015, Jas
Mike,
Thanks for your feedback.
I'll be changing this fix to introduce new algorithm Strings to specify
the P1363 format. These strings will be of the form:
withinFormat
For example:
SHA1withDSAinP1363Format
SHA1withECDSAinP1363Format
The intent is to reduce potential confusion with
TestDSA2
- can you add an @bug 8042967 to each of these tests, since you are
extending them to test this new format.
- can you also add a test which uses the
SignatureFormatParameterSpec.ASN1 enum (by passing it to setParameter)?
--Sean
On 01/22/2015 09:46 PM, Jason Uh wrote:
Please revie
Please review this change, which enables DSA and ECDSA signatures in the
IEEE P1363 format (the concatenation of r and s).
This is accomplished through an implementation of
AlgorithmParameterSpec, SignatureFormatParameterSpec, which can be
passed to the existing Signature.setParameter() method
gs_Id;
+critical = true;
(Good catch, Jamil.)
Jason
On 1/13/15 4:55 AM, Sean Mullan wrote:
Looks good to me.
--Sean
On 01/12/2015 06:56 PM, Jason Uh wrote:
Please review this change, which changes the default criticality of the
policy mappings and policy constraints certificate extensions.
Please review this change, which changes the default criticality of the
policy mappings and policy constraints certificate extensions. This
change makes both extensions critical by default, per RFC 5280.
webrev: http://cr.openjdk.java.net/~juh/8059916/01/webrev
bug: https://bugs.openjdk.java.ne
Thanks, I'll push after I remove that comment.
Jason
On 01/09/2015 10:50 AM, Sean Mullan wrote:
On 01/08/2015 09:46 PM, Jason Uh wrote:
Thanks, Sean.
Here is an updated webrev with your suggested changes. I've also added
tests here, and will no longer be adding tests for this ch
wn on line 498)
520,524: these methods should be private
--Sean
On 12/16/2014 02:44 PM, Jason Uh wrote:
Please review this fix, which allows XML Signature ECKeyValue elements
to be marshalled and unmarshalled.
Dependence on internal sun.security.* classes has been removed, so that
the (un)marsha
Please review this fix, which allows XML Signature ECKeyValue elements
to be marshalled and unmarshalled.
Dependence on internal sun.security.* classes has been removed, so that
the (un)marshalling can happen without reflection.
webrev: http://cr.openjdk.java.net/~juh/8046724/00/
bug: https:/
Vote: Yes
Jason
On 11/03/2014 09:28 AM, Sean Mullan wrote:
I hereby nominate Anthony Scarpino to Membership in the Security Group.
Anthony is a member of the Java Security Libraries team at Oracle and
has been an active contributor to the OpenJDK Security Group for
approximately two years. Ant
Please review this changeset, which updates references to RFC 3280 to
RFC 5280. RFC 5280 has obsoleted 3280.
http://cr.openjdk.java.net/~juh/8037550/webrev.03/
Thanks,
Jason
Please review this change, which adds a constructor taking an algorithm
name parameter to EncodedKeySpec and its subclasses. This allows the
algorithm name to be retrieved in subsequent calls to the EncodedKeySpec.
webrev: http://cr.openjdk.java.net/~juh/8047223/webrev.01/
https://bugs.openjdk.
son,
Please review the updated webrev . I have addressed your comments.
http://cr.openjdk.java.net/~tyan/raghu/8049039/webrev03/
<http://cr.openjdk.java.net/%7Etyan/raghu/8049039/webrev03/>
Thanks,
Raghu
On 9/3/2014 12:47 AM, Jason Uh wrote:
On 8/27/14 8:34 AM, raghu k.nair wrote:
Hi
014 9:43 AM, raghu k.nair wrote:
Hi Jason,
Thanks for your review comments.
On 8/26/2014 11:37 PM, Jason Uh wrote:
Hi Raghu,
I'm not an official Reviewer, but I have some comments, mostly about
X509Test.java.
1. I'm not sure if this matters, but the formatting of your copyright
heade
Hi Raghu,
I'm not an official Reviewer, but I have some comments, mostly about
X509Test.java.
1. I'm not sure if this matters, but the formatting of your copyright
header is a little strange. The text appears to be correct, but the line
breaks occur at non-standard places. If you look at any
On 08/25/2014 04:14 PM, Sean Mullan wrote:
On 08/25/2014 04:05 PM, Jason Uh wrote:
On 08/25/2014 03:41 PM, Sean Mullan wrote:
Just a couple of comments:
1. I think the check on lines 106-110 can be done prior to the for loop
on line 94
I think that check is actually where it should be
(Everything now says "DNSNames".)
Updated webrev here:
http://cr.openjdk.java.net/~juh/8054380/webrev.03/
Thanks,
Jason
--Sean
On 08/22/2014 05:07 PM, Jason Uh wrote:
Please see the revised webrev here:
http://cr.openjdk.java.net/~juh/8054380/webrev.02/
Additional changes include:
1. V
Please see the revised webrev here:
http://cr.openjdk.java.net/~juh/8054380/webrev.02/
Additional changes include:
1. Verification of the DNSName during certificate parsing
2. Allowing each component to start with a letter or digit
2. A check to make sure the final character of a component ends i
Please review this fix, which allows the first character of a DNSName in
a SubjectAltName to be either a letter or a digit.
http://cr.openjdk.java.net/~juh/8054380/webrev.01/
This change is to stay compliant with RFC 1123:
RFC 1123, Section 2.1:
One aspect of host name syntax is hereby chang
Thanks, Florian. I will withdraw my review request and close this issue.
I'll file a separate bug to allow the first character to be a digit, as
RFC 1123 relaxed that restriction.
Thanks,
Jason
On 08/04/2014 11:58 PM, Florian Weimer wrote:
On 08/05/2014 07:52 AM, Jason Uh wrote:
Hi Fl
implementations MUST NOT encode strings that include
either the at sign or underscore character as PrintableString.
RFC 5280 doesn't allow underscores for *PrintableString*, but DNSName is
an *IA5String*, which does support them.
Jason
On 08/04/2014 03:50 AM, Florian Weimer wrote:
On
Hi Max,
Could you please review this fix?
http://cr.openjdk.java.net/~juh/8007706/webrev.00/
With the fix, the rules will be:
1. A DNSName must begin with a letter or a digit
2. After the first character, valid characters in DNSName components are
letters, digits, hyphens, and underscores
A
Hi Xuelei,
Could you please review this change?
webrev: http://cr.openjdk.java.net/~juh/7065233/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-7065233
I don't think any of the strings in the lines I changed would be
locale-sensitive. There are a few cases fixed here that weren't inclu
Hi Robert,
This was actually fixed in
https://bugs.openjdk.java.net/browse/JDK-8021804 and is pending a
backport to JDK 7u.
Thanks,
Jason
On 5/28/14 4:04 PM, Robert Gibson wrote:
Hi,
I was researching a StackOverflow question [1] and I came across some behaviour
with the validation of cert
383 * is part of this this AP-REQ.
"this" is repeated.
Jason
On 3/12/14 7:18 PM, Wang Weijun wrote:
Tiny webrev at
http://cr.openjdk.java.net/~weijun/8037262/webrev.00/
Thanks
Max
! Check out other tests to see examples.
Otherwise, fix looks good and you can push without a re-review.
--Sean
On 03/10/2014 08:00 PM, Jason Uh wrote:
Thanks, Sean. I've simplified my changes to only removing the call to
setValidityPeriod.
http://cr.openjdk.java.net/~juh/8021804/webrev.0
les.
Otherwise, fix looks good and you can push without a re-review.
--Sean
On 03/10/2014 08:00 PM, Jason Uh wrote:
Thanks, Sean. I've simplified my changes to only removing the call to
setValidityPeriod.
http://cr.openjdk.java.net/~juh/8021804/webrev.01
Jason
On 3/10/14 12:00 PM, Se
Thanks, Sean. I've simplified my changes to only removing the call to
setValidityPeriod.
http://cr.openjdk.java.net/~juh/8021804/webrev.01
Jason
On 3/10/14 12:00 PM, Sean Mullan wrote:
Hi Jason,
Sorry for the delay in reviewing this.
On 02/28/2014 02:54 PM, Jason Uh wrote:
Hi Sean,
Please review this fix for 8036844, which updates the path to a keystore
used in a couple of tests. The path is no longer accurate after the
recent changes to the JSSE test hierarchy. This webrev also includes a
patch from Max for an enhancement to printssl.sh to correctly handle a
failure in P
On 3/3/14 5:38 AM, Sean Mullan wrote:
On 02/28/2014 02:56 PM, Jason Uh wrote:
Could I please get a review of this change?
Looks fine to me, but the priority should be higher if this requires a
backport to 7u. Also, the bug should be labeled with "8-na" and "9-na"
since thi
Do I need more than one noreg tag? I already have noreg-sqe.
On 2/28/14 3:31 PM, Xuelei Fan wrote:
Looks fine to me. noreg-trivial tag?
Xuelei
On 3/1/2014 3:56 AM, Jason Uh wrote:
Could I please get a review of this change?
Just a simple fix for 7u-dev that adds a check for a null
Could I please get a review of this change?
Just a simple fix for 7u-dev that adds a check for a null CertStore, in
case URICertStore.getInstance returns null.
webrev: http://cr.openjdk.java.net/~juh/8035973/webrev.00/
bug: http://bugs.openjdk.java.net/browse/JDK-8035973
noreg-sqe because an
Hi Sean,
Could I please get a review of this change? This fix allows a certpath
to be validated when a certificate issued by a version 1 trusted cert
has a validity period that doesn't fall within the validity of the
issuer. Trust anchors whose validity do contain the issued cert's
validity p
On 2/14/14 7:17 AM, Sean Mullan wrote:
On 02/13/2014 10:04 PM, Jason Uh wrote:
Hi Sean,
Looks good to me, but I'm not an official Reviewer.
I have a couple of questions, though.
Sure.
1. This isn't a part of your change, but shouldn't the comment
Hi Sean,
Looks good to me, but I'm not an official Reviewer.
I have a couple of questions, though.
1. This isn't a part of your change, but shouldn't the comment on line
200 of AdaptableX509CertSelector.java read "As for version 3,..." and
not "As for version 2,..."?
2. Just curious, any re
Hi all,
Please review this fix for JDK 9, which checks for an empty cert path
list in RevocationChecker.
webrev: http://cr.openjdk.java.net/~juh/8031025/webrev.01
noreq-sqe, as the fix can be verified with existing SQE tests.
Thanks,
Jason
Hi Vinnie,
The change looks good to me.
Jason
(Not an official Reviewer)
On 12/9/13 3:25 PM, Vincent Ryan wrote:
Please review this fix to the OCSPResponse class in the internal
sun.security.provider.certpath package. Previously, when validating
an OCSP response, it expected the supplied issu
Changeset: d6c4ae56c079
Author:juh
Date: 2013-12-06 11:36 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d6c4ae56c079
8007967: Infinite loop can happen in
sun.security.provider.certpath.SunCertPathBuilder.depthFirstSearchForward()
Reviewed-by: mullan
! src/share/classes/sun
/2013 04:04 PM, Jason Uh wrote:
Thanks, Sean.
I've updated the webrev with your suggestions. Also, I've changed the
check for loops in ForwardBuilder.java to bail out whenever the same
certificate is encountered twice.
Please note that none of the policy mapping tests in the NIST PKITS
d @code tags, that is only for
javadoc comments.
--Sean
On 12/03/2013 01:51 PM, Jason Uh wrote:
Could I please get a review for this change? This change fixes some
issues in CertPath building and CRL verification. The main components of
this fix are:
1. Proper setting of TrustAnchors when verifyi
Thanks for fixing these, Joe! The changes look good.
Jason
On 12/03/2013 09:40 AM, Joe Darcy wrote:
Hello,
Please review my fixes for
JDK-8029475 Fix more doclint issues in javax.security
http://cr.openjdk.java.net/~darcy/8029475.0/
Changes also in-line below.
Thanks,
-Jo
Could I please get a review for this change? This change fixes some
issues in CertPath building and CRL verification. The main components of
this fix are:
1. Proper setting of TrustAnchors when verifying indirect CRLs obtained
from CRL Distribution Points. I added an overloaded getCRLs() metho
Changeset: 5ac7cd164300
Author:juh
Date: 2013-11-27 15:25 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ac7cd164300
8021418: Intermittent: SSLSocketSSLEngineTemplate.java test fails with timeout
Reviewed-by: xuelei, wetmore
Contributed-by: rajan.hal...@oracle.com
! test/su
Changeset: c956a5d0618f
Author:juh
Date: 2013-10-22 11:57 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c956a5d0618f
8025287: NPE in
api/java_security/cert/PKIXRevocationChecker/GeneralTests_GeneralTests
Reviewed-by: mullan
! src/share/classes/sun/security/provider/certpat
System.out.println("Testing that get methods return null or " +
"empty lists/sets/maps");
requireNull(prc.getOcspResponder(), "getOcspResponder()");
--Sean
On 10/21/2013 08:12 PM, Jason Uh wrote:
Hi Sean,
Could I please get
Changeset: 975e3a89814e
Author:darcy
Date: 2013-10-21 13:36 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/975e3a89814e
8024603: Turn on javac lint checking for auxiliaryclass, empty, and try in jdk
build
Reviewed-by: erikj, ihse, chegar
! makefiles/Setup.gmk
Changeset: f4
Hi Sean,
Could I please get a review of this changeset?
The change checks for null params when RevocationChecker.init is called.
Bug: https://bugs.openjdk.java.net/browse/JDK-8025287
Webrev: http://cr.openjdk.java.net/~juh/8025287/webrev.00/
Thanks,
Jason
Changeset: fa38f8e0accd
Author:juh
Date: 2013-10-17 12:00 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fa38f8e0accd
8026233: test/sun/security/tools/keytool/StorePasswords.java needs to clean up
files
Reviewed-by: vinnie
! test/sun/security/tools/keytool/StorePasswords.ja
01:57, Jason Uh wrote:
Hi Vinnie,
Could you please review this fix? The test
sun/security/tools/keytool/StorePasswords.java can terminate with an error on
Windows because of files not getting cleaned up, so this fix deletes the
keystore file at the end of the test.
webrev: http://cr.openjdk.jav
more like a jtreg issue if it cannot
deal with that slash.
I haven't noticed it failing on Windows before. Can you point me to a
jtr file.
Thanks
Max
On 10/10/13 8:56 AM, Jason Uh wrote:
Please review this fix. This changeset removes trailing slashes at the
end of the test library pat
Please review this fix. This changeset removes trailing slashes at the
end of the test library paths in the jtreg @library tag, which can cause
the tests to fail on Windows.
webrev: http://cr.openjdk.java.net/~juh/8026052/webrev.00/
Thanks,
Jason
Hi Vinnie,
Could you please review this fix? The test
sun/security/tools/keytool/StorePasswords.java can terminate with an
error on Windows because of files not getting cleaned up, so this fix
deletes the keystore file at the end of the test.
webrev: http://cr.openjdk.java.net/~juh/8026233/w
Changeset: e4c897b33cb7
Author:ascarpino
Date: 2013-09-02 09:52 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4c897b33cb7
8009438: sun/security/pkcs11/Secmod tests failing on Ubuntu 12.04
Reviewed-by: vinnie
! src/share/classes/sun/security/pkcs11/Secmod.java
Changeset: 2434e79fc41f
Author:ascarpino
Date: 2013-09-18 14:57 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2434e79fc41f
8004283: test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failing
intermittently
Reviewed-by: vinnie
! test/sun/security/pkcs11/KeyStore/SecretKey
Changeset: d0de46a2cbd0
Author:ascarpino
Date: 2013-09-19 11:59 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d0de46a2cbd0
7122707: Security Providers need to have their version numbers updated for JDK8
Reviewed-by: xuelei
! src/macosx/classes/apple/security/AppleProvider.j
Thanks for catching that. I'll include that correction, too.
Jason
On 9/9/13 8:30 AM, Sean Mullan wrote:
CertPathBuilderSpi
[90]: should be "{@code CertPathChecker}"
--Sean
On 09/06/2013 05:40 PM, Jason Uh wrote:
Hi Joe,
Please review this fix, which fixes do
Changeset: be0bcd6a904e
Author:juh
Date: 2013-09-09 10:52 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/be0bcd6a904e
8024432: Fix doclint issues in java.security
Reviewed-by: darcy, mullan
! src/share/classes/java/security/AccessController.java
! src/share/classes/java/secu
Thanks, Joe. I'll make that revision before I push.
On 09/06/2013 03:20 PM, Joseph Darcy wrote:
Hi Jason,
For the serialVersionUID changes, I recommend using "type" rather than
"class". Otherwise, the changes look fine.
Thanks,
-Joe
On 9/6/2013 2:40 PM, Jason U
Hi Joe,
Please review this fix, which fixes doclint issues in
java.security
java.security.cert
java.security.interfaces
webrev: http://cr.openjdk.java.net/~juh/8024432/webrev.00/
Changes have been checked against specdiff.
Thanks,
Jason
Changeset: 67edbf7e6b26
Author:juh
Date: 2013-08-08 17:06 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/67edbf7e6b26
8022461: Fix lint warnings in sun.security.{provider,rsa,x509}
Reviewed-by: darcy, weijun, xuelei, mullan
! src/share/classes/sun/security/provider/DSAPublic
On 08/07/2013 04:49 PM, Weijun Wang wrote:
On 8/8/13 7:13 AM, Jason Uh wrote:
On 8/6/13 6:30 PM, Weijun Wang wrote:
One question:
In src/share/classes/sun/security/x509/X509Key.java, two fields are now
not recommended:
@Deprecated
protected byte[] key = null
x
On 8/7/13 7:51 AM, Joe Darcy wrote:
Hi Jason,
Looks fine to me, but a security reviewer should approve as well.
Thanks,
-Joe
On 08/06/2013 04:46 PM, Jason Uh wrote:
Joe, Sean,
Could I please get a review of this changeset? This change fixes
deprecation warnings in:
sun.security.p
Joe, Sean,
Could I please get a review of this changeset? This change fixes
deprecation warnings in:
sun.security.provider
sun.security.rsa
sun.security.x509
In sun.security.provider and sun.security.rsa, I change the use of
sun.security.x509.X509Key's key bytes to the BitArray form of the
Changeset: 69cfd941aec2
Author:juh
Date: 2013-08-06 14:10 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/69cfd941aec2
8022443: Fix lint warnings in sun.security.pkcs12
Reviewed-by: darcy
! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java
Hi Joe,
Please review this changeset, which fixes lint deprecation warnings in
sun.security.pkcs12.
http://cr.openjdk.java.net/~juh/8022443/webrev.00/
Thanks!
Jason
Changeset: 8112076ae424
Author:juh
Date: 2013-08-06 13:46 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8112076ae424
8022439: Fix lint warnings in sun.security.ec
Reviewed-by: darcy
! src/share/classes/sun/security/ec/ECDSASignature.java
Hi Joe,
Could you please review this changeset, which takes care of deprecation
warnings in sun.security.ec?
http://cr.openjdk.java.net/~juh/8022439/webrev.00
Thanks,
Jason
Changeset: c76f89695c90
Author:juh
Date: 2013-07-30 11:04 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c76f89695c90
8021833: javadoc cleanup in java.net
Summary: and converted to {@code }; package.html to
package-info.java
Reviewed-by: darcy, chegar
! src/share/classes/
Changeset: e47569593fa0
Author:ascarpino
Date: 2013-07-29 13:43 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e47569593fa0
8020424: The NSS version should be detected before running crypto tests
Reviewed-by: valeriep
! test/ProblemList.txt
! test/sun/security/pkcs11/KeyStor
Changeset: c042fd498f79
Author:ascarpino
Date: 2013-07-19 11:34 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c042fd498f79
8012971: PKCS11Test hiding exception failures
Reviewed-by: vinnie, valeriep
! test/ProblemList.txt
! test/sun/security/pkcs11/PKCS11Test.java
! test/su
Changeset: 7ae061cfd4be
Author:juh
Date: 2013-07-26 14:16 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ae061cfd4be
8019544: Need to run ProviderTest.java in othervm mode.
Reviewed-by: wetmore, xuelei, vinnie
Contributed-by: rajan.hal...@oracle.com
! test/sun/security/ssl/
Changeset: f9224fb49890
Author:juh
Date: 2013-07-24 12:48 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f9224fb49890
8016916: UnstructuredName should support DirectoryString
Reviewed-by: mullan
! src/share/classes/sun/security/pkcs/PKCS9Attribute.java
! src/share/classes/su
1 - 100 of 161 matches
Mail list logo
