Weijun Max Wang wrote:
Hi Guys
What's the best way to find out what ProtectionDomains are effective
currently (or for a given AccessControlContext)?
For "effective", I mean those since the last doPrivileged call.
I think you could do that with a DomainCombiner, ex:
- create an AccessContr
FYI.
--- Begin Message ---
The following JSR is now available for review:
SR 321 - Trusted Computing API for JavaTM
http://jcp.org/en/jsr/detail?id=321
"Develop a Trusted Computing API for Java^TM providing selected
functionality the TCG Software Stack offers to the C world, while
We will be using this mailing list to discuss topics related to the design
and implementation of the security component of the OpenJDK. So, there is
nothing that you specifically need to do to participate in (or start) a
discussion, other than subscribe to the alias. Can you be more specific?
--Se
Hi Max,
The fix looks fine.
--Sean
Max (Weijun) Wang wrote:
Hi Sean
There's a bug on spec inside javax.security.cert.X509Certificate
-START BUG REPORT-
6634644 broken fragment, should use @link
Broken fragment in api doc, following lines in
javax/security/cert/X509Certificate.java
Weijun Max Wang wrote:
Hi All
I've tried to disable realm name case check in JDK (equals ->
equalsIgnoreCase), and it works. In fact, I do several experiments to
change the case of principal names, realm names, service names and
hostnames, and MSAD just doesn't care. This is another case of
Micr
Changeset: 6068b786e186
Author:mullan
Date: 2008-03-13 13:29 -0400
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/6068b786e186
6611991: Add support for parsing RFC4514 DNs to X500Principal
Summary: Added new test and made one code change to escape null characters.
Reviewed-by: vin
Hi JKT,
David Herron wrote:
JKT wrote:
Hi to all,
I tried to generated a xmldsig signature by using the JSR105 API. It
works well except the fact that I cannot use other signature methods
than DSA_SHA1, RSA_SHA1 and HMAC_SHA1.
Right. The API is lacking a feature that allows you to extend
Changeset: aabdc646cb31
Author:mullan
Date: 2008-04-14 10:25 -0400
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/aabdc646cb31
6631361: Spec of AccessControlContext constructor is not complete
Summary: Add NullPointerException to @throws clause and treat empty array and
array of
Changeset: 072695f32409
Author:mullan
Date: 2008-04-25 08:58 -0400
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/072695f32409
6690169: Specification for BasicPermission.equals() is not consistent
Summary: Clarified @return to be consistent with method description
Reviewed-by: vin
FYI, in case you had not seen this announcement.
--Sean
--- Begin Message ---
A new Request for Comments is now available in online RFC libraries.
RFC 5280
Title: Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation
Looks fine to me.
--Sean
Max (Weijun) Wang wrote:
Hi All
Please take a review.
Bug:
http://bugs.sun.com/view_bug.do?bug_id=6711509
Code changes:
diff --git a/src/share/classes/sun/security/tools/PolicyTool.java
b/src/share/classes/sun/security/tools/PolicyTool.java
--- a/src/share/clas
Changeset: 2f21c9f8136a
Author:mullan
Date: 2008-06-17 10:34 -0400
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/2f21c9f8136a
6673277: Thread unsafe lazy initialization code in
sun.security.provider.certpath.*Checker classes
Summary: make supportedExts variable non-static
Review
Changeset: 4be8dfa19e27
Author:mullan
Date: 2008-06-19 14:20 -0400
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/4be8dfa19e27
6714842: CertPathBuilder returns incorrect CertPath for BasicConstraints in
builderParams
Summary: Do not consider CA target certificates if
selector.ge
I have asked someone who worked on this code and they said:
I believe this is a failsafe to prevent the code from going into an
infinite loop when talking to a bad card or driver.
--Sean
Ming Yung wrote:
Hi there,
This relates to a limitation (bug?) in the implementation of
javax.smartcardi
Exception message is extremely misleading, by the way. If it wasn't
for jpcsc I would have believed that the card did actually stop responding.
Thanks,
Ming
On Tue, Jul 29, 2008 at 1:14 AM, Sean Mullan <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
I have asked
Changeset: 80fe10573687
Author:mullan
Date: 2008-09-11 14:05 -0400
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/80fe10573687
6465942: Add problem identification facility to the CertPathValidator framework
Summary: Add support to the java.security.cert APIs for determining the re
Changeset: 74fc78477907
Author:mullan
Date: 2008-09-22 10:43 -0400
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/74fc78477907
6469266: Integrate Apache XMLSec 1.4.2 into JDK 7
Reviewed-by: valeriep
! src/share/classes/com/sun/org/apache/xml/internal/security/Init.java
!
src/sha
Changeset: 486b917ed417
Author:mullan
Date: 2008-10-07 13:41 -0400
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/486b917ed417
6752764: PIT B37: CertPath/CertPathValidatorTest/KeyParamsInheritanceTest failed
Summary: fix regression introduced by 6465942
Reviewed-by: vinnie
! src/
I looked at the code changes and it seems fine to me.
--Sean
Joe Darcy wrote:
Hello.
On 10/16/08 12:46 PM, Martin Buchholz wrote:
Hi all,
This is a bug report with fix.
Joe Darcy, please file a bug and review this change,
I've filed 6761678 "(ann) SecurityException in
AnnotationInvocat
Changeset: 4ff842aee1fd
Author:mullan
Date: 2008-10-30 17:24 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4ff842aee1fd
6764553: com.sun.org.apache.xml.internal.security.utils.IdResolver is not
thread safe
Reviewed-by: valeriep
!
src/share/classes/com/sun/org/apache/xml/i
Changeset: 5102df668164
Author:mullan
Date: 2008-11-05 15:55 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5102df668164
6744888: OCSP validation code should permit some clock skew when checking
validity of OCSP responses
Summary: Allow for up to 10 minutes of clock skew whe
Changeset: 3a3e02a55de8
Author:mullan
Date: 2008-11-06 12:12 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3a3e02a55de8
6765046: CertPathValidatorException(Throwable).getMessage() always returns null
since b37
Reviewed-by: vinnie
! src/share/classes/java/security/cert/Cert
Changeset: 31cb1c17f524
Author:mullan
Date: 2008-11-25 10:17 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/31cb1c17f524
6728890: Add SwissSign root certificates to the JDK
6732157: Add VeriSign TSA Root Cert to the JDK
6754779: Add Camerfirma root certificates to the JDK
676
Hi Bruno,
Bruno Harbulot wrote:
Hi Xuelei,
Thanks for looking into this.
I agree with you, everything that's required is already in the JavaSE
API. I find, however, that using these classes requires a careful
reading of the JSSE ref. guide and the Certification path ref. guide,
both of which
Max (Weijun) Wang wrote:
On Feb 18, 2009, at 6:17 PM, Xuelei Fan wrote:
> If you find the webrev too long, you might only review a part of it.
sun/security/x509/SubjectInfoAccessExtension.java:
This class looks fine for me except that the SubjectInfoAccessSyntax
is introduced from RFC3280,
Hi Max,
I only had time to do a quick review of KeyTool.java but everything else
looks good.
--Sean
Max (Weijun) Wang wrote:
Hi All
Can you take a review of this RFE?
6780416: New keytool commands/options: -gencert, -printcertreq, -ext
bug: http://bugs.sun.com/view_bug.do?bug_id=678041
The W3C XML Security Working Group has just released 7 first public working
drafts of new XML Signature and Encryption specifications. If you use or are
interested in JSR 105 (Java XML Digital Signature API) or JSR 106 (Java XML
Encryption API), please try to review them and send any comments yo
Hi Max,
Can you review: http://cr.openjdk.java.net/~mullan/6787130/webrev/
Thanks,
Sean
Changeset: c769c46c27ce
Author:mullan
Date: 2009-03-09 09:46 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c769c46c27ce
6787130: java.policy file contains stale link to http://java.sun.com/notes
Reviewed-by: weijun
! src/share/lib/security/java.policy
Changeset: aa48deaf9a
Weijun Wang wrote:
Hi
In keytool's installReply(), there is:
if (replyCerts.length == 1) {
// single-cert reply
newChain = establishCertChain(userCert, replyCerts[0]);
} else {
// cert-chain reply (e.g., PKCS#7)
newChain = validate
Xuelei Fan wrote:
In line 318, if "idpExt == null" is true, "false" will return. I don't
find any spec support such logic, it might be a bug here. I think the
codes should looks like:
318 if (idpExt != null &&
319 ((Boolean) idpExt.get
320
Xuelei Fan wrote:
Many, many Verisign root certs are V1, and the intermediate cert are V3.
I believe that is because many Verisign roots were issued in the late 1990's and
perhaps v3 (published in 1996) had not gained enough support in the market yet.
I am wondering if you know if there are
The fix looks fine to me.
--Sean
Xuelei Fan wrote:
Hi,
The RSA OID from sun.security.x509.AlgorithmId is 1.2.5.8.1.1. However
no such OID seems to exist. The correct one should be 2.5.8.1.1.
ITU-T X.509 defined RSA encryption algorithm as:
id-ea-rsa = {joint-iso-itu-t(2) ds(5) algorithm(8)
Changeset: 4da7b972b391
Author:mullan
Date: 2009-06-10 09:12 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4da7b972b391
6845161: Bottleneck in Configuration.getConfiguration synchronized call
Summary: Reduce scope of synchronized block
Reviewed-by: weijun
! src/share/classe
Changeset: e387bb1367a7
Author:mullan
Date: 2009-06-18 09:04 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e387bb1367a7
6833839: RFE: improve ManifestDigester by instantiating StringBuilder
constructor w/ initial value
Reviewed-by: weijun
! src/share/classes/sun/security/u
Hi Andrew,
Here are some comments -
ForwardBuilder:
line 864:
typo: s/abchor/anchor
In this block of code:
858 if (principal != null && publicKey != null &&
859 principal.equals(cert.getSubjectX500Principal())) {
860 if (publicKe
Some additional comments in the new tests describing what path building
scenarios are being tested would be very useful.
A few comments below. Everything else looks good.
Xuelei Fan wrote:
new webrev: http://cr.openjdk.java.net/~xuelei/6852744/webrev.01/
Sean Mullan wrote:
Hi Andrew,
Here
Xuelei Fan wrote:
In this block of code:
858 if (principal != null && publicKey != null &&
859
principal.equals(cert.getSubjectX500Principal())) {
860 if (publicKey.equals(cert.getPublicKey())) {
861 this
Xuelei Fan wrote:
webrev updated, adding comments to tests:
http://cr.openjdk.java.net/~xuelei/6852744/webrev.02/
In DisableRevocation.java, why do you add CRLs to the CertStore if revocation is
disabled?
I think I understand what are your concerns now. If I'm right, you think
that the ta
FYI. In future, we should think about enhancing the existing
java.security.cert.TrustAnchor class to support this new structure.
--Sean
--- Begin Message ---
The IESG has received a request from the Public-Key Infrastructure
(X.509) WG (pkix) to consider the following document:
- 'Trust Ancho
Changeset: 1203425b5742
Author:mullan
Date: 2009-07-20 17:16 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1203425b5742
6787645: CRL validation code should permit some clock skew when checking
validity of CRLs
Reviewed-by: vinnie
! src/share/classes/java/security/cert/Cert
Hi Najeeb,
Please see an earlier message/thread about a DTLS implementation:
http://mail.openjdk.java.net/pipermail/security-dev/2008-January/50.html
I am not sure what the status of that project is, but I suggest you try
to contact Christian to see what the status is and if you can help.
Changeset: 8252729d51a3
Author:mullan
Date: 2009-09-09 09:54 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8252729d51a3
6745437: Add option to only check revocation of end-entity certificate in a
chain of certificates
6869739: Cannot check revocation of single certificate w
Looks good to me.
Super small nit in SecurityConstants:
120try {
indentation is off by one space with rest of code.
--Sean
Alan Bateman wrote:
Sean, Mandy - can you review this? I also need someone from the AWT team.
This patch eliminates the static dependency on ja
Looks good.
--Sean
Alan Bateman wrote:
Vinnie, Sean,
The Sun provider has a dependency on JNDI due to the LDAP CertStore
implementation to fetch certs and CRLs from an LDAP directory. I'd like
to remove this dependency with the following patch:
http://cr.openjdk.java.net/~alanb/6889552/
In
Changeset: 5f326176855d
Author:mullan
Date: 2009-10-14 09:36 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5f326176855d
6885667: CertPath/CertPathValidatorTest/bugs/bug6383078 fails on jdk6u18/b02,
jdk7/pit/b73 and passes on b72.
Summary: Wrap all OCSP exceptions in CertPat
Changeset: 6fac6e5fdf0c
Author:mullan
Date: 2009-11-18 12:34 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6fac6e5fdf0c
6894461: OCSP Checker should not wrap all Exception as "Unable to send OCSP
request."(introduced by #6885667)
Reviewed-by: vinnie, xuelei
! src/share/cla
Mandy Chung wrote:
Fixed 6903638: Remove dependency on AuthPermission from SecurityConstants
Webrev at:
http://cr.openjdk.java.net/~mchung/6903638/webrev.00/
Move the two static fields defined in the SecurityConstants to
javax.security.auth.Subject class. javax.security.auth classes are not
Changeset: 5d2e63dad298
Author:mullan
Date: 2009-11-23 12:36 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5d2e63dad298
6899503: Security code issue using Verisign root certificate
Summary: Add support for reordering out-of-order certificate chains
Reviewed-by: vinnie, xuele
Changeset: 7c9be6c9385a
Author:mullan
Date: 2009-12-10 11:31 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7c9be6c9385a
6867348: Digest Value of References inside Manifest - calculation order problem
Reviewed-by: xuelei
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX
Hi Todd,
This should be fixed in OpenJDK 7. Can you test against JDK 7 to see if it works
and I'll investigate porting the fix to OpenJDK 6?
--Sean
Todd E. Johnson wrote:
Hello,
I posted a bug on this issue at http://bugreport.sun.com/
The Sun provider currently ignores all but the first S
A new version (3.0) of the Secure Coding Guidelines for the Java Programming
Language has just been published at http://java.sun.com/security/seccodeguide.html
The secure coding guidelines documents best practices and patterns that you
should adhere to when writing Java code in order to avoid v
Changeset: 51d62db10c93
Author:mullan
Date: 2010-01-15 09:48 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/51d62db10c93
6915939: Exception should be thrown if OCSP SingleResponses contain unresolved
critical extensions
Reviewed-by: xuelei
! src/share/classes/sun/security/p
Looks fine to me.
--Sean
Max (Weijun) Wang wrote:
Hi All
Please take a review at --
http://cr.openjdk.java.net/~weijun/6919610/webrev.00
Bug description follows.
Thanks
Max
*Change Request ID*: 6919610
*Synopsis*: KeyTabInputStream uses static field for per-instance value
Product:
Looks fine to me.
--Sean
Vincent Ryan wrote:
Please review this minor change to eliminate a reference to the
sun.security.provider.IdentityDatabase class in the java.security
configuration file. That class was removed as part of our
modularization effort.
http://cr.openjdk.java.net/~vinnie/69
Alan Bateman wrote:
Christopher Hegarty -Sun Microsystems Ireland wrote:
:
Alan is correct there are already tests for SSL/Https in javax.net,
but I believe these use self signed certs, no dependency on cacerts.
OK, in that case adding a new test make sense. The test/java/net tree is
probably
Christopher Hegarty -Sun Microsystems Ireland wrote:
Pavel Tisnovsky wrote:
Christopher Hegarty -Sun Microsystems Ireland wrote:
Alan Bateman wrote:
Pavel Tisnovsky wrote:
Hi,
please review new regression test for java.net.* API. This test
check if the cacerts keytool database is configured
Andrew John Hughes wrote:
This has been posted about before; OpenJDK currently can't bootstrap
itself because it doesn't have a working cacerts store (the JAXP URL
uses https).
I don't know how to solve this; we can certainly have the cacerts file
populated on GNU/Linux systems, but I don't hav
Andrew John Hughes wrote:
On 18 March 2010 21:12, Christopher Hegarty -Sun Microsystems Ireland
wrote:
Andrew John Hughes wrote:
On 18 March 2010 20:56, Christopher Hegarty -Sun Microsystems Ireland
wrote:
Brad, Pavel, Andrew,
I'm also not comfortable with this test, but what bothers me mor
Andrew John Hughes wrote:
On Windows you can use the "Windows-ROOT" KeyStore type, ex:
keytool -list -keystore NONE -storetype Windows-ROOT
Ok, so that presumably makes some Windows system call, right?
Yes.
I haven't tried it, but you could probably use the keytool -importkeystore
opti
Hi Andrew,
Could I get a quick code review for 6909281 which also needs to be fixed in JDK
7:
http://cr.openjdk.java.net/~mullan/6909281/webrev/
Thanks,
Sean
Changeset: 710c4493902f
Author:mullan
Date: 2010-04-09 07:21 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/710c4493902f
6909281: 6u19 b99(pit):Error loading first applet in browser session( both FF
&& IE, windows ): NPE is thrown
Summary: Fix for 6633872 causes NPE due to u
Looks good to me.
--Sean
On 4/27/10 4:44 AM, Weijun Wang wrote:
Hi
Simple fix, webrev at
http://cr.openjdk.java.net/~weijun/6947487/webrev.00
Thanks
Max
Begin forwarded message:
*Change Request ID*: 6947487
*Synopsis*: use HexDumpEncoder.encodeBuffer()
=== *Description*
Yes, looks good to me.
--Sean
Xuelei Fan wrote:
Looks fine to me.
Andrew
On 5/21/2010 5:34 PM, Weijun Wang wrote:
Hi Sean and Andrew
This webrev is 6948803 for opejdk-7. Please review it:
http://cr.openjdk.java.net/~weijun/6948803/webrev.00/
The src/ changes are identical to the 6u21 o
Changeset: 9bffc32b645d
Author:mullan
Date: 2010-07-01 15:20 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9bffc32b645d
6782979: Add JNLPAppletLauncher (6618105) to blacklist
Reviewed-by: ohair
! make/java/security/Makefile
Changeset: c0d2a097eb99
Author:mullan
Date:
Hi,
I would like to try to fix a long-standing XMLDSig issue with the current DSA
and ECDSA signature bytes format.
The format of the Signature bytes for these algorithms is an ASN.1 encoded
sequence of the integers r and s:
SEQUENCE ::= { r INTEGER, s INTEGER }
Unfortunately, this is no
Hi Maarten,
Thanks for the comments, a few replies below -
Maarten Bodewes wrote:
On Thu, Jul 15, 2010 at 6:57 PM, Sean Mullan <mailto:sean.mul...@oracle.com>> wrote:
I would like to try to fix a long-standing XMLDSig issue with the
current DSA and ECDSA signature byt
On 7/19/10 5:32 PM, Maarten Bodewes wrote:
Darn, that was a bit premature, I don't see how the PKCS#11 provider can
support this. Currently it only lists the SHA256withECDSA and such.
This would make it near impossible to directly perform XML signatures
using a HSM or software PKCS#11 lib.
I'm
Changeset: 9d1994d53a67
Author:mullan
Date: 2010-07-20 10:41 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9d1994d53a67
6870553: X509Certificate.getSigAlgName method description uses non-standard
algorithm name as example
Reviewed-by: xuelei
! src/share/classes/java/securi
Hi Max,
I'm not sure about this change. There's a definitely a change in behavior.
Before generateCertificate would only read one PEM block from the stream, and
throw an exception if it wasn't a certificate. But the current fix ignores non
certificate blocks until it finds a certificate or end
Hi Max,
Can you review this simple fix?
http://cr.openjdk.java.net/~mullan/6653372/webrev.00/
Thanks,
Sean
icate
blocks. I suppose one could interpret it that way, but I would be wary of
changing the behavior after so many years.
Also, I'm wondering why the submitter could not have caught the exception and
continued to read the rest of the data?
--Sean
Thanks Max
On Jul 31, 2010, at 12:46 AM,
Changeset: a21c46dac6cf
Author:mullan
Date: 2010-08-03 09:39 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a21c46dac6cf
6653372: Error in java.security.KeyStore example code
Reviewed-by: weijun
! src/share/classes/java/security/KeyStore.java
Changeset: 2feeefb45a44
Author:
On 03/29/2013 08:32 PM, Valerie (Yu-Ching) Peng wrote:
Trivial fix - just add null check and OOM error handling for the 2
malloc calls inside
src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c.
Please find webrev against JDK8 at:
http://cr.openjdk.java.net/~valeriep/7107615/webrev.00/
Wr
On 04/06/2013 04:22 AM, Damian Kolasa wrote:
Hi all,
I only wanted to point out that You might need to review the
java.security file because recent versions of xmlsec, changed provider
package to:
org.apache.jcp.xml.dsig.internal.dom
adding "apache" in between org and jcp.
The Apache Santuar
On 04/11/2013 04:36 AM, Weijun Wang wrote:
Hi All
The KeyStore::setCertificateEntry has
* @exception KeyStoreException if the keystore has not been initialized,
* or the given alias already exists and does not identify an
* entry containing a trusted certificate,
* or this operation fails for s
Looks good. One comment. In PKCS7.java, can you document the new
tSAPolicyId parameter in the javadoc.
--Sean
On 04/10/2013 10:06 PM, Weijun Wang wrote:
Hi Sean
Please review the code changes
http://cr.openjdk.java.net/~weijun/8009636/webrev.00/
Here I add a new -tsapolicycd option to j
Hi Vinnie,
Could I get a code review for the fix for 8011313:
http://cr.openjdk.java.net/~mullan/webrevs/8011313/webrev.00/
The bug has been tagged with noreg-sqe since there is an existing SQE
test for this.
Thanks,
Sean
This fix adds support for 2 new system properties to allow users to
adjust the maximum allowable clock skew when validating OCSP responses,
and a maximum connection timeout for downloading CRLs.
webrev: http://cr.openjdk.java.net/~mullan/webrevs/8013228/webrev.00/
Thanks,
Sean
Looks fine to me.
--Sean
On 05/16/2013 10:17 PM, Weijun Wang wrote:
Hi All
Please take a look at
http://cr.openjdk.java.net/~weijun/8012261/webrev.00/
which supports the new HttpURLPermission type introduced in
8010464: Evolve java networking same origin policy
http://hg.open
On 06/07/2013 09:42 AM, Weijun Wang wrote:
Hi All
The GSSContext::initSecContext() method could either return a token
(possibly null if no more token is needed) when the call succeeds or
throw a GSSException if there is a failure, but not *both*. The same
applies to acceptSecContext().
However,
Why did you need to check for a $HOME/.java.policy file in i18n.sh? Can
you explain that?
Otherwise, changes look good to me.
--Sean
On 06/08/2013 09:32 PM, Weijun Wang wrote:
Updated at
http://cr.openjdk.java.net/~weijun/8015274/webrev.01/
A new bug 8016158 is added.
The changes inclu
rning should be created.
Ok, can you add a comment about that for future reference?
Thanks,
Sean
-Max
On 6/11/13 9:16 PM, Sean Mullan wrote:
Why did you need to check for a $HOME/.java.policy file in i18n.sh? Can
you explain that?
Otherwise, changes look good to me.
--Sean
On 06/08/2013 0
(cc-ing security-dev for comments)
Original thread is at
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017912.html
--Sean
On 06/12/2013 11:17 AM, Brian Burkhalter wrote:
On Jun 12, 2013, at 6:19 AM, Florian Weimer wrote:
On 06/11/2013 11:31 PM, Brian Burkhalter wrote:
W
Changeset: f695f447f6b7
Author:jzavgren
Date: 2013-06-14 09:13 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f695f447f6b7
8014307: Memory leak ... security/jgss/wrapper/GSSLibStub.c
Summary: I modified the native procedure:
Java_sun_security_jgss_wrapper_GSSLibStub_initCont
Looks good, just a couple of comments:
1. I think the name "nssOptimizeSpace" is clearer. The "Use" part seems
a bit odd in the property name.
2. Add the appropriate noreg label to the bug.
3. File a followup doc bug to document the attribute in the PKCS11 guide.
--Sean
On 06/19/2013 08:49
On 06/24/2013 10:38 AM, Vincent Ryan wrote:
Hello all,
The fix to handle Authority Key IDs also applies to Subject Key IDs so I've
duplicated the changes:
http://cr.openjdk.java.net/~vinnie/8014805/webrev.01
1211 subjectKeyId = id.getIdentifier();
Should "id" be "
Looks good.
--Sean
On 06/24/2013 02:33 PM, Vincent Ryan wrote:
I've updated the webrev to address your comments:
http://cr.openjdk.java.net/~vinnie/8014805/webrev.02/
Thanks.
On 24 Jun 2013, at 16:24, Sean Mullan wrote:
On 06/24/2013 10:38 AM, Vincent Ryan wrote:
Hello all,
Th
Hi Xuelei,
Please review my JDK 8 code changes to bring our XML Signature
implementation up-to-date with Apache Santuario version 1.5.4.
The changes are extensive, but many of them are simple formatting or
refactoring changes. Any questions, let me know.
http://cr.openjdk.java.net/~mullan/w
On 07/01/2013 07:02 PM, Xuelei Fan wrote:
On 7/1/2013 8:56 PM, Vincent Ryan wrote:
I think that wrapping a RuntimeException (in CPVE) is acceptable in this case
because the goal is to activate the failover mechanism from OCSP to CRL.
Do you want RuntimeException to be re-thrown?
No. It is acc
ption thrown in that block is an IOException, so the
extra try/catch blocks for RuntimeException and Exception are unnecessary.
--Sean
On 2 Jul 2013, at 16:19, Sean Mullan wrote:
On 07/01/2013 07:02 PM, Xuelei Fan wrote:
On 7/1/2013 8:56 PM, Vincent Ryan wrote:
I think that wrapp
Changeset: 028ef97797c1
Author:mullan
Date: 2013-07-05 15:54 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/028ef97797c1
8011547: Update XML Signature implementation to Apache Santuario 1.5.4
Reviewed-by: xuelei
!
src/share/classes/com/sun/org/apache/xml/internal/security/a
Hi Xuelei,
Can you please review my fix for JDK-8017173? This is a regression
introduced in 7u25. It does not affect JDK 8, because the recent fix for
JDK-8011547 to integrate the Apache Santuario release 1.5.4 also fixed
this issue. However, I am not backporting the JDK 8 code, which is more
Looks fine.
--Sean
On 07/09/2013 03:32 AM, Weijun Wang wrote:
Hi All
An NPE was suppressed in jdk8 with a simple if. This new fix tries to
output useful info even for a null argument.
Please review the code changes at
http://cr.openjdk.java.net/~weijun/8019267/webrev.01/
The added test
Looks good to me.
--Sean
On 07/09/2013 09:28 AM, Seán Coffey wrote:
I'd like to move this testcase from our internal test repo and replace
the current "test/java/lang/SecurityManager/CheckPackageAccess.java"
testcase . It's a straightforward test to ensure that the package
restrictions enforced
/
Thanks
Max
On 7/9/13 8:16 PM, Sean Mullan wrote:
Looks fine.
--Sean
On 07/09/2013 03:32 AM, Weijun Wang wrote:
Hi All
An NPE was suppressed in jdk8 with a simple if. This new fix tries to
output useful info even for a null argument.
Please review the code changes at
http
Looks fine to me.
--Sean
On 07/12/2013 03:19 AM, Weijun Wang wrote:
Please take a look at
http://cr.openjdk.java.net/~weijun/8019410/webrev.00/
The ReplayCacheTestProc test fails on linux-i586 with MIT krb5 1.6.1
installed. The reason is that the acceptor does not start at all using
nativ
Please review my JDK 8 fix for 8010748:
http://bugs.sun.com/view_bug.do?bug_id=8010748
This add a few useful API additions to JEP 124 (Enhance the Certificate
Revocation-Checking API) from experience with using the API.
webrev: http://cr.openjdk.java.net/~mullan/webrevs/8010748/webrev.00/
Looks good.
--Sean
On 07/19/2013 12:39 PM, Vincent Ryan wrote:
Please review the following change to correct the handling of backdated OCSP
requests:
Bug: http://bugs.sun.com/view_bug.do?bug_id=8020940 [not yet visible]
Webrev: http://cr.openjdk.java.net/~vinnie/8020940/webrev.00
It modifie
Xuelei,
Could you please review my fix for 8012288:
http://cr.openjdk.java.net/~mullan/webrevs/8012288/webrev.00/
There is already an SQE test for this, so I have added the noreg-sqe label.
Thanks,
Sean
1 - 100 of 2385 matches
Mail list logo
