From weijun.wang at oracle.com  Mon Feb  2 13:47:36 2015
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 02 Feb 2015 21:47:36 +0800
Subject: RFR 8071643: sun.security.krb5.KrbApReq.authenticate() is not thread
	safe
Message-ID: <54CF7FF8.9040009@oracle.com>

Hi All

Please review the code change at

   http://cr.openjdk.java.net/~weijun/8071643/webrev.00/

The static field is removed and a local MessageDigest is used. The 
getInstance() method might spend some time but since there are already 
quite some cipher and checksum operations during an AP-REQ receive, this 
change does not make much difference.

No reg, could be -hard and -trivial.

Thanks
Max

From bradford.wetmore at oracle.com  Mon Feb  2 19:27:01 2015
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Mon, 02 Feb 2015 11:27:01 -0800
Subject: JEP Review Request: TLS Application-Layer Protocol Negotiation
	Extension
Message-ID: <54CFCF85.7020105@oracle.com>

The draft JEP ?TLS Application-Layer Protocol Negotiation Extension? is 
now available for community review:

    https://bugs.openjdk.java.net/browse/JDK-8051498

This JEP is to add support for the Application Layer Protocol 
Negotiation (ALPN) TLS Hello extension [1] in JSSE. ALPN provides a 
mechanism for declaring the application protocols that are supported 
over a TLS connection.

We need this functionality to make JDK 9, so this JEP needs to get into 
the JEP pipeline soon.  Community review is a precursor in the process 
before it can move to "Submitted."

For now, there is a simple API proposed (similar to JDK 8 SNI), but I'm 
parsing the discussions that took place on security-dev in August[2], 
September[3], and November 2014[4], and the current API is likely not 
flexible enough.

Thanks,

Brad

[1] http://www.rfc-editor.org/rfc/rfc7301.txt

[2] 
http://mail.openjdk.java.net/pipermail/security-dev/2014-August/thread.html
[3] 
http://mail.openjdk.java.net/pipermail/security-dev/2014-September/thread.html

Subject: TLS extensions API, ALPN and HTTP 2.0

[4] 
http://mail.openjdk.java.net/pipermail/security-dev/2014-November/thread.html

Subject: ALPN API Proposal
Subject: A fully fledged TLS Extensions API ?
Subject: ALPN & HTTP2


From simone.bordet at gmail.com  Tue Feb  3 08:43:09 2015
From: simone.bordet at gmail.com (Simone Bordet)
Date: Tue, 3 Feb 2015 09:43:09 +0100
Subject: JEP Review Request: TLS Application-Layer Protocol Negotiation
	Extension
In-Reply-To: <54CFCF85.7020105@oracle.com>
References: <54CFCF85.7020105@oracle.com>
Message-ID: <CAFWmRJ3cn9RHnb1R_PR1vhB5oLS6Gm7QYYJ7e2oXcdHuwKVWxw@mail.gmail.com>

Hi,

On Mon, Feb 2, 2015 at 8:27 PM, Bradford Wetmore
<bradford.wetmore at oracle.com> wrote:
> The draft JEP ?TLS Application-Layer Protocol Negotiation Extension? is now
> available for community review:
>
>    https://bugs.openjdk.java.net/browse/JDK-8051498
>
> This JEP is to add support for the Application Layer Protocol Negotiation
> (ALPN) TLS Hello extension [1] in JSSE. ALPN provides a mechanism for
> declaring the application protocols that are supported over a TLS
> connection.
>
> We need this functionality to make JDK 9, so this JEP needs to get into the
> JEP pipeline soon.  Community review is a precursor in the process before it
> can move to "Submitted."
>
> For now, there is a simple API proposed (similar to JDK 8 SNI), but I'm
> parsing the discussions that took place on security-dev in August[2],
> September[3], and November 2014[4], and the current API is likely not
> flexible enough.

I have taken a quick look at the proposed API as reported here:
https://bugs.openjdk.java.net/browse/JDK-8062848.

I don't think it is enough, since what needs to be provided by the API
is the ability to run application code.
That is the API must be something like:

sslParameters.setALPNSelector(protocols -> protocols.get(0));

That is, it should take a lambda of the form:

public String select(List<String> protocols);

Also, the lambda would be different for clients and servers.

See my November message for further details:
http://mail.openjdk.java.net/pipermail/security-dev/2014-November/011399.html

Somehow orthogonal to this, the HTTP2 working group has finally
stabilized the requirements for negotiating HTTP2.
For a server that receives a list of ALPN protocols, and that wants to
negotiate "h2", it has not only check that both itself and the client
support the "h2" protocol, but also that the cipher requirements for
HTTP2 are satisfied.
Note that this requirement only exist for negotiating HTTP2.

While I agree that the major use case for ALPN is HTTP2, ALPN is
nevertheless a generic mechanism to negotiate the application protocol
over TLS, so the HTTP2 cipher selection should not be "hardcoded".
So perhaps the JDK should also provide a utility class, say
HTTP2ALPNServerSelector, which implements the before mentioned lambda
adding the specific HTTP2 cipher logic, although this may be out of
scope for this ALPN work.
I mentioned it as a reminder that the API cannot be too "closed", as
the protocol selection may need to access contextual information such
as the TSL protocol version, the negotiated cipher, possibly the
server name indication, etc.

Thanks !

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

From jaroslav.bachorik at oracle.com  Tue Feb  3 09:42:05 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 03 Feb 2015 10:42:05 +0100
Subject: RFR 8064331: JavaSecurityAccess.doIntersectionPrivilege() drops the
	information about the domain combiner of the stack ACC
Message-ID: <54D097ED.9080409@oracle.com>

Please, review the following change to j.s.ProtectionDomain

Issue : https://bugs.openjdk.java.net/browse/JDK-8064331
Webrev: http://cr.openjdk.java.net/~jbachorik/8064331/webrev.01

This issue was reported against the JMX functionality. When a user tries 
to do the following
```
AccessControlContext acc = AccessController.getContext();
Subject subject = Subject.getSubject(acc);
```
the subject is always null even though it should contain the currently 
authenticated Subject.

The reason for this is the combination of the facts that JMX is using 
JavaSecurityAccess.doIntersectionPrivilege(actin, stackACC, savedACC) to 
invoke a code in the combined access control context and this method 
just drops the information about the domain combiner of the stack ACC.

In turn, Subject.getSubject(acc) relies on a correct domain container 
used in the current ACC and fails.

The fix is to make the 
JavaSecurityAccess.doIntersectionPrivilege(action, stackACC, savedACC) 
to pay attention to the domain combiner of the stackACC.

Thanks,

-JB-

From fweimer at redhat.com  Tue Feb  3 10:42:48 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 03 Feb 2015 11:42:48 +0100
Subject: RFR 8072394: Performance improvement for X.509 certificate parsing
Message-ID: <54D0A628.3080404@redhat.com>

The sun.security.x509.PolicyInformation constructor creates
java.security.cert.PolicyQualifierInfo instances and adds them to a
LinkedHashSet. PolicyQualifierInfo does not override hashCode(), so the
default implementation based on System.identityHashCode() is used, which
is rather slow.

I addressed this by implementing an explicit, identity-based hashCode()
using an atomic counter.  Another approach would be to replace the
LinkedHashSet with a Set backed by an ArrayList.

  <http://cr.openjdk.java.net/~fweimer/8072394/webrev.00/>

Before the change, this particular call to Object#hashCode() accounted
for 25% of all hits in hprof.

My benchmark involved parsing 1,000,000 certificates from the Google
certificate transparency log.  The benchmark times includes loading the
DER-encoded certificates from an SQLite database.  They are quite noisy
because the X.509 parsing code allocates heavily.

R says this about this change (run time is measured in seconds):

> old <- c(50.246, 51.237, 50.057, 49.611, 49.895, 49.268, 50.161,
49.992, 49.972, 50.380)
> new <- c(50.386, 50.628, 49.496, 49.196, 49.581, 49.845, 50.009,
49.229, 48.138, 48.762)
> t.test(old, new)

	Welch Two Sample t-test

data:  old and new
t = 1.9356, df = 16.015, p-value = 0.07077
alternative hypothesis: true difference in means is not equal to 0
95 percent confidence interval:
 -0.05278151  1.16258151
sample estimates:
mean of x mean of y
  50.0819   49.5270



-- 
Florian Weimer / Red Hat Product Security


From xuelei.fan at oracle.com  Tue Feb  3 14:18:31 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 03 Feb 2015 22:18:31 +0800
Subject: RFR: 8061798: Add support for TLS_FALLBACK_SCSV
In-Reply-To: <54CA048B.7040409@redhat.com>
References: <54C6112E.7030806@redhat.com> <54C9AB70.6070802@oracle.com>
	<54CA048B.7040409@redhat.com>
Message-ID: <54D0D8B7.7030503@oracle.com>

On 1/29/2015 5:59 PM, Florian Weimer wrote:
> On 01/29/2015 04:39 AM, Xuelei Fan wrote:
>> Hi Florian,
>>
>> Thanks for contribute this patch to OpenJDK.
>>
>> The draft of TLS_FALLBACK_SCSV is moving pretty fast.  Would you mind
>> wait for the integration until it becomes an official RFC in order to
>> mitigate the potential compatibility impact?
> 
> The RFC is basically set in stone because code implementing it has
> already been shipped.  I don't like the specification, and I don't like
> how it happened.  But practically speaking, it's a done deal, even if
> the IETF end up not publishing the RFC (which is extremely unlikely
> because an RFC is the only way to get the SCSV code point reservation).
> 
We may still have a few months to address this feature of JDK 9. I think
it might not be bad to wait for more progress of this RFC proposal, in
case the spec gets updates unexpectedly.

>> I looked back the approach we used to support
>> TLS_EMPTY_RENEGOTIATION_INFO_SCSV (RFC 5746).
>> TLS_EMPTY_RENEGOTIATION_INFO_SCSV is treated as a cipher suite.
>> Application can configure to enabled or disable this special cipher
>> suite as normal:
>>     SSLSocket.setEnabledCipherSuites(String[] suites)
>>     SSSEngine.setEnabledCipherSuites(String[] suites)
>>
>> What do you think if we use TLS_FALLBACK_SCSV as a cipher suite? If the
>> enabled cipher suite list contains this cipher suites, client would send
>> this cipher suite in ClientHello request.
> 
> We absolutely have to prevent that application developers set this SCSV
> by accident.  Developers feel tempted to set TLS_FALLBACK_SCSV to
> increase security, but this is very wrong.  Things will appear to work
> just fine right now, but if the server side ever upgrades to TLS 1.3,
> the handshake will fail to work (I called this a ?time bomb? in the IETF
> TLS WG discussion, because that's what it is).  Questions on the OpenSSL
> mailing list (and misleading advice in response) show that this is a
> real problem.
> 
> My hope is that with a new API, the risk that developers enable this
> accidentally is reduced.  It makes it also more transparent to code reviews.
> 
It depends.  In other side, as would decrease the transparent for system
administrators.

>> If it is OK, may not need to define new public APIs any more.  As make
>> it possible if this implementation is needed to backport to previous
>> releases (In general, no APIs changes are allowed in JDK update releases).
> 
> I plan to backport only the server part, the client part is mostly there
> for testing purposes.
> 
I would suggest to keep the JSSE APIs simple and small.  If an public
API is required to turn on/off TLS_FALLBACK_SCSV, using cipher suite is
an easy-to-use approach.

Thanks,
Xuelei

From fweimer at redhat.com  Tue Feb  3 15:29:56 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 03 Feb 2015 16:29:56 +0100
Subject: RFR: 8061798: Add support for TLS_FALLBACK_SCSV
In-Reply-To: <54D0D8B7.7030503@oracle.com>
References: <54C6112E.7030806@redhat.com> <54C9AB70.6070802@oracle.com>
	<54CA048B.7040409@redhat.com> <54D0D8B7.7030503@oracle.com>
Message-ID: <54D0E974.6090402@redhat.com>

On 02/03/2015 03:18 PM, Xuelei Fan wrote:
> On 1/29/2015 5:59 PM, Florian Weimer wrote:
>> On 01/29/2015 04:39 AM, Xuelei Fan wrote:
>>> Hi Florian,
>>>
>>> Thanks for contribute this patch to OpenJDK.
>>>
>>> The draft of TLS_FALLBACK_SCSV is moving pretty fast.  Would you mind
>>> wait for the integration until it becomes an official RFC in order to
>>> mitigate the potential compatibility impact?
>>
>> The RFC is basically set in stone because code implementing it has
>> already been shipped.  I don't like the specification, and I don't like
>> how it happened.  But practically speaking, it's a done deal, even if
>> the IETF end up not publishing the RFC (which is extremely unlikely
>> because an RFC is the only way to get the SCSV code point reservation).
>>
> We may still have a few months to address this feature of JDK 9. I think
> it might not be bad to wait for more progress of this RFC proposal, in
> case the spec gets updates unexpectedly.

I don't think this will happen because both NSS and OpenSSL implement
already with specific semantics, and the changes have been backported
all over the place.  The Internet draft might still die and never be
promoted to an RFC, though.

My worry here is that PCI DSS compliance will eventually require
TLS_FALLBACK_SCSV support (in the sense that you have to write up an
excuse for an exception) once Microsoft ISS implements it.  If that
happens, we are in a bit of pain, considering the release schedules we
have with OpenJDK.

>>> I looked back the approach we used to support
>>> TLS_EMPTY_RENEGOTIATION_INFO_SCSV (RFC 5746).
>>> TLS_EMPTY_RENEGOTIATION_INFO_SCSV is treated as a cipher suite.
>>> Application can configure to enabled or disable this special cipher
>>> suite as normal:
>>>     SSLSocket.setEnabledCipherSuites(String[] suites)
>>>     SSSEngine.setEnabledCipherSuites(String[] suites)
>>>
>>> What do you think if we use TLS_FALLBACK_SCSV as a cipher suite? If the
>>> enabled cipher suite list contains this cipher suites, client would send
>>> this cipher suite in ClientHello request.
>>
>> We absolutely have to prevent that application developers set this SCSV
>> by accident.  Developers feel tempted to set TLS_FALLBACK_SCSV to
>> increase security, but this is very wrong.  Things will appear to work
>> just fine right now, but if the server side ever upgrades to TLS 1.3,
>> the handshake will fail to work (I called this a ?time bomb? in the IETF
>> TLS WG discussion, because that's what it is).  Questions on the OpenSSL
>> mailing list (and misleading advice in response) show that this is a
>> real problem.
>>
>> My hope is that with a new API, the risk that developers enable this
>> accidentally is reduced.  It makes it also more transparent to code reviews.
>>
> It depends.  In other side, as would decrease the transparent for system
> administrators.

I'm sorry, the key point I'm trying to bring across here is that this is
*not* a configuration issue.  System administrators must not configure
TLS_FALLBACK_SCSV.  The *only* valid use for TLS_FALLBACK_SCSV is in
this code sequence:

  1. Code makes a TLS connection with all supported protocols,
     without sending TLS_FALLBACK_SCSV.

  2. Code catches a handshake-related exception.

  3. Code retries the handshake, this time with a subset of the
     supported protocols, and sets TLS_FALLBACK_SCSV.

If the system administrator has a way to configure TLS_FALLBACK_SCSV,
this code sequence breaks because the first step *must not* send
TLS_FALLBACK_SCSV for forward compatibility with TLS 1.3.

Or, more relevant to typical Java clients, code which doesn't do step 2
and 3 must not send TLS_FALLBACK_SCSV, ever.  This is an absolute fringe
feature, and the only use case we might ever encounter could be
self-testing of the server-side support.

Past experience with the OpenSSL implementation suggests that developers
are eternally tempted to get this wrong.  That's why I don't want to
turn it into a cipher suite, so that it's more likely that developers
read the Javadoc warning before activating this.

>>> If it is OK, may not need to define new public APIs any more.  As make
>>> it possible if this implementation is needed to backport to previous
>>> releases (In general, no APIs changes are allowed in JDK update releases).
>>
>> I plan to backport only the server part, the client part is mostly there
>> for testing purposes.
>>
> I would suggest to keep the JSSE APIs simple and small.  If an public
> API is required to turn on/off TLS_FALLBACK_SCSV, using cipher suite is
> an easy-to-use approach.

I'm worried that it's too error-prone and will result in broken Java
clients because developers pick up incorrect advice somewhere that they
have to set TLS_FALLBACK_SCSV (for example, there already posts on the
web which confuse it with TLS_EMPTY_RENEGOTIATION_INFO_SCSV).

-- 
Florian Weimer / Red Hat Product Security

From ecki at zusammenkunft.net  Wed Feb  4 21:21:30 2015
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 4 Feb 2015 22:21:30 +0100
Subject: constant time compare is not used anywhere important
Message-ID: <20150204222130.00002422.ecki@zusammenkunft.net>

Hello,

while researching on the SSL3 rsaHandshakeFix (dont ask :) I noticed
that JSSE uses Arrays.equals() in some places to compare
byte arrays with cryptographic material, at least
in one instance it does even use it to verify and reject a MAC in a
network protocol.

I am not sure if this specific instance is anyway near to beeing
relevant. Especially as I suspect there might be things
(like intrinsics) going on as this is really wrong all over
the place.

I think the openjdk code should anyway follow best practice and avoid a
optimized equals method in all crypto code.


functions working on key material, password hashes or macs:

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/security/Identity.java#272
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/javax/crypto/spec/SecretKeySpec.java#229
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/sun/security/pkcs11/wrapper/Functions.java#460
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/sun/security/rsa/RSASignature.java#197
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/sun/security/pkcs12/PKCS12KeyStore.java#2005
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/com/sun/crypto/provider/AESCrypt.java#91
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/com/sun/crypto/provider/CipherCore.java#570
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/com/sun/crypto/provider/PBKDF2KeyImpl.java#155
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/security/Signature.java#1274
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/com/sun/crypto/provider/DESKey.java#116

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/sun/security/ssl/HandshakeMessage.java#1910



Most likely uncritical but still in crypto code:

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/security/cert/Certificate.java#116
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/com/sun/crypto/provider/PBMAC1Core.java#138
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/sun/security/krb5/internal/KRBError.java#494
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/security/cert/X509CertSelector.java#2072
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/org/ietf/jgss/ChannelBinding.java#194
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/javax/crypto/spec/RC2ParameterSpec.java#144
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/sun/security/pkcs11/P11KeyStore.java#2463


(there are more)

I guess all of them can be converted to MessageDigst.equals(). And as
this is branch free, it might not even be slower. (I am not sure if
an intrinsic applied here)

Gruss
Bernd

PS: (i know, non-comment policy but I dont really see a reason to
embargo this. Java is hardly a good candidate for safe crypto
(unfortunatelly).

From sean.mullan at oracle.com  Wed Feb  4 21:49:04 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 04 Feb 2015 16:49:04 -0500
Subject: RFR 8071643: sun.security.krb5.KrbApReq.authenticate() is not
	thread safe
In-Reply-To: <54CF7FF8.9040009@oracle.com>
References: <54CF7FF8.9040009@oracle.com>
Message-ID: <54D293D0.8050201@oracle.com>

Looks fine to me.

--Sean

On 02/02/2015 08:47 AM, Weijun Wang wrote:
> Hi All
>
> Please review the code change at
>
>    http://cr.openjdk.java.net/~weijun/8071643/webrev.00/
>
> The static field is removed and a local MessageDigest is used. The
> getInstance() method might spend some time but since there are already
> quite some cipher and checksum operations during an AP-REQ receive, this
> change does not make much difference.
>
> No reg, could be -hard and -trivial.
>
> Thanks
> Max

From weijun.wang at oracle.com  Thu Feb  5 11:54:58 2015
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 05 Feb 2015 19:54:58 +0800
Subject: RFR 8072615:
	test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java
	wrong on Windows
Message-ID: <54D35A12.4080608@oracle.com>

Hi All

A test helper tries to parse the "test.src.path" system property using 
delimiter ":". This is not correct on Windows.

The fix is simply

diff --git a/test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java 
b/test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java
--- a/test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java
+++ b/test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java
@@ -56,7 +56,7 @@
       */
      public SimpleSSLContext () throws IOException {
          String paths = System.getProperty("test.src.path");
-        StringTokenizer st = new StringTokenizer(paths,":");
+        StringTokenizer st = new StringTokenizer(paths, 
File.pathSeparator);
          boolean securityExceptions = false;
          while (st.hasMoreTokens()) {
              String path = st.nextToken();

The test still runs fine now, because when "C:\x;c:\y" is divided into 
"C", "\x;c" and "\y". The useful part "\y" still somehow works. If 
test.src and jtreg working directory are on different drives, the test 
would fail.

Thanks
Max

From xuelei.fan at oracle.com  Thu Feb  5 12:03:13 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 05 Feb 2015 20:03:13 +0800
Subject: RFR 8072615:
	test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java
	wrong on Windows
In-Reply-To: <54D35A12.4080608@oracle.com>
References: <54D35A12.4080608@oracle.com>
Message-ID: <54D35C01.8090208@oracle.com>

Good catch!

Looks fine to me.

Xuelei

On 2/5/2015 7:54 PM, Weijun Wang wrote:
> Hi All
> 
> A test helper tries to parse the "test.src.path" system property using
> delimiter ":". This is not correct on Windows.
> 
> The fix is simply
> 
> diff --git a/test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java
> b/test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java
> --- a/test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java
> +++ b/test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java
> @@ -56,7 +56,7 @@
>       */
>      public SimpleSSLContext () throws IOException {
>          String paths = System.getProperty("test.src.path");
> -        StringTokenizer st = new StringTokenizer(paths,":");
> +        StringTokenizer st = new StringTokenizer(paths,
> File.pathSeparator);
>          boolean securityExceptions = false;
>          while (st.hasMoreTokens()) {
>              String path = st.nextToken();
> 
> The test still runs fine now, because when "C:\x;c:\y" is divided into
> "C", "\x;c" and "\y". The useful part "\y" still somehow works. If
> test.src and jtreg working directory are on different drives, the test
> would fail.
> 
> Thanks
> Max


From sean.mullan at oracle.com  Thu Feb  5 22:19:45 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 05 Feb 2015 17:19:45 -0500
Subject: RFR 8064331: JavaSecurityAccess.doIntersectionPrivilege() drops
	the information about the domain combiner of the stack ACC
In-Reply-To: <54D097ED.9080409@oracle.com>
References: <54D097ED.9080409@oracle.com>
Message-ID: <54D3EC81.2090700@oracle.com>

The copyright on the test should be at the top. Otherwise, this fix
looks good to me.

--Sean

On 02/03/2015 04:42 AM, Jaroslav Bachorik wrote:
> Please, review the following change to j.s.ProtectionDomain
> 
> Issue : https://bugs.openjdk.java.net/browse/JDK-8064331
> Webrev: http://cr.openjdk.java.net/~jbachorik/8064331/webrev.01
> 
> This issue was reported against the JMX functionality. When a user tries
> to do the following
> ```
> AccessControlContext acc = AccessController.getContext();
> Subject subject = Subject.getSubject(acc);
> ```
> the subject is always null even though it should contain the currently
> authenticated Subject.
> 
> The reason for this is the combination of the facts that JMX is using
> JavaSecurityAccess.doIntersectionPrivilege(actin, stackACC, savedACC) to
> invoke a code in the combined access control context and this method
> just drops the information about the domain combiner of the stack ACC.
> 
> In turn, Subject.getSubject(acc) relies on a correct domain container
> used in the current ACC and fails.
> 
> The fix is to make the
> JavaSecurityAccess.doIntersectionPrivilege(action, stackACC, savedACC)
> to pay attention to the domain combiner of the stackACC.
> 
> Thanks,
> 
> -JB-

From weijun.wang at oracle.com  Fri Feb  6 02:18:56 2015
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 06 Feb 2015 10:18:56 +0800
Subject: RFR JDK-8071338: Move policytool from JRE to JDK
In-Reply-To: <54D423F9.70307@oracle.com>
References: <54D423F9.70307@oracle.com>
Message-ID: <54D42490.3050501@oracle.com>

Hi All

Please review this change at

root: http://cr.openjdk.java.net/~weijun/8071338/root/webrev.00/
jdk:  http://cr.openjdk.java.net/~weijun/8071338/jdk/webrev.00/

No actual java code change, just move everything inside the 
s.s.t.policytool into another module. There are other make/test changes 
though.

Thanks
Max

From mandy.chung at oracle.com  Fri Feb  6 02:44:25 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 05 Feb 2015 18:44:25 -0800
Subject: RFR JDK-8071338: Move policytool from JRE to JDK
In-Reply-To: <54D42490.3050501@oracle.com>
References: <54D423F9.70307@oracle.com> <54D42490.3050501@oracle.com>
Message-ID: <54D42A89.5030308@oracle.com>


On 2/5/2015 6:18 PM, Weijun Wang wrote:
> Hi All
>
> Please review this change at
>
> root: http://cr.openjdk.java.net/~weijun/8071338/root/webrev.00/
> jdk:  http://cr.openjdk.java.net/~weijun/8071338/jdk/webrev.00/
>
> No actual java code change, just move everything inside the 
> s.s.t.policytool into another module. There are other make/test 
> changes though.

Looks good to me.
Mandy


From Alan.Bateman at oracle.com  Fri Feb  6 07:44:56 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 06 Feb 2015 07:44:56 +0000
Subject: RFR JDK-8071338: Move policytool from JRE to JDK
In-Reply-To: <54D42490.3050501@oracle.com>
References: <54D423F9.70307@oracle.com> <54D42490.3050501@oracle.com>
Message-ID: <54D470F8.6000309@oracle.com>

On 06/02/2015 02:18, Weijun Wang wrote:
> Hi All
>
> Please review this change at
>
> root: http://cr.openjdk.java.net/~weijun/8071338/root/webrev.00/
> jdk:  http://cr.openjdk.java.net/~weijun/8071338/jdk/webrev.00/
>
> No actual java code change, just move everything inside the 
> s.s.t.policytool into another module. There are other make/test 
> changes though.
Looks like you've caught everything, it looks good.

-Alan.

From magnus.ihse.bursie at oracle.com  Fri Feb  6 10:48:01 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 06 Feb 2015 11:48:01 +0100
Subject: RFR JDK-8071338: Move policytool from JRE to JDK
In-Reply-To: <54D42490.3050501@oracle.com>
References: <54D423F9.70307@oracle.com> <54D42490.3050501@oracle.com>
Message-ID: <54D49BE1.8030809@oracle.com>

On 2015-02-06 03:18, Weijun Wang wrote:
> Hi All
>
> Please review this change at
>
> root: http://cr.openjdk.java.net/~weijun/8071338/root/webrev.00/
> jdk:  http://cr.openjdk.java.net/~weijun/8071338/jdk/webrev.00/
>
> No actual java code change, just move everything inside the 
> s.s.t.policytool into another module. There are other make/test 
> changes though.

Please note that build/makefile changes should be reviewed by the build 
team as well.

Consider it done now. :-)

/Magnus

From fweimer at redhat.com  Mon Feb  9 19:15:30 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 09 Feb 2015 20:15:30 +0100
Subject: RFR 8069072: GHASH performance improvement
Message-ID: <54D90752.3010503@redhat.com>

Micro-benchmarks show a ten-fold performance increase, which is very
noticeable with TLS connections using the AES-GCM cipher suites, as
discussed here:


<http://mail.openjdk.java.net/pipermail/security-dev/2014-August/011009.html>

and here:


<http://mail.openjdk.java.net/pipermail/security-dev/2014-November/011458.html>

The latest webrev is here.  Compared to the original submission,
copyright lines were updated, and the bug number was added:

  <http://cr.openjdk.java.net/~fweimer/8069072/webrev.03/>

-- 
Florian Weimer / Red Hat Product Security

From sean.mullan at oracle.com  Mon Feb  9 19:48:36 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 09 Feb 2015 14:48:36 -0500
Subject: RFR 8069072: GHASH performance improvement
In-Reply-To: <54D90752.3010503@redhat.com>
References: <54D90752.3010503@redhat.com>
Message-ID: <54D90F14.7040205@oracle.com>

This updated webrev looks good to me.

--Sean

On 02/09/2015 02:15 PM, Florian Weimer wrote:
> Micro-benchmarks show a ten-fold performance increase, which is very
> noticeable with TLS connections using the AES-GCM cipher suites, as
> discussed here:
>
>
> <http://mail.openjdk.java.net/pipermail/security-dev/2014-August/011009.html>
>
> and here:
>
>
> <http://mail.openjdk.java.net/pipermail/security-dev/2014-November/011458.html>
>
> The latest webrev is here.  Compared to the original submission,
> copyright lines were updated, and the bug number was added:
>
>    <http://cr.openjdk.java.net/~fweimer/8069072/webrev.03/>
>

From joe.darcy at oracle.com  Tue Feb 10 00:28:53 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 09 Feb 2015 16:28:53 -0800
Subject: JDK 9 RFR of JDK-8069277: Doclint regression in
	java/security/KeyStore.java
Message-ID: <54D950C5.1020906@oracle.com>

Hello,

As the final purge of doclint warnings from the java.base module 
approaches, please review the changes for

     JDK-8069277: Doclint regression in java/security/KeyStore.java
     http://cr.openjdk.java.net/~darcy/8069277.0/

Patch below.

Thanks,

-Joe

--- old/src/java.base/share/classes/java/security/KeyStore.java 
2015-02-09 16:25:01.853908872 -0800
+++ new/src/java.base/share/classes/java/security/KeyStore.java 
2015-02-09 16:25:01.529912945 -0800
@@ -1618,11 +1618,13 @@
       * integrity check.
       *
       * <p>
-     * This method traverses the list of registered security {@link 
Providers},
-     * starting with the most preferred Provider.
-     * For each {@link KeyStoreSpi} implementation supported by a Provider,
-     * it invokes the {@link engineProbe} method to determine if it 
supports
-     * the specified keystore.
+     * This method traverses the list of registered security
+     * {@linkplain Provider providers}, starting with the most
+     * preferred Provider.
+     * For each {@link KeyStoreSpi} implementation supported by a
+     * Provider, it invokes the {@link
+     * KeyStoreSpi#engineProbe(InputStream) engineProbe} method to
+     * determine if it supports the specified keystore.
       * A new KeyStore object is returned that encapsulates the KeyStoreSpi
       * implementation from the first Provider that supports the 
specified file.
       *
@@ -1672,11 +1674,12 @@
       * unlock the keystore data or perform an integrity check.
       *
       * <p>
-     * This method traverses the list of registered security {@link 
Providers},
-     * starting with the most preferred Provider.
-     * For each {@link KeyStoreSpi} implementation supported by a Provider,
-     * it invokes the {@link engineProbe} method to determine if it 
supports
-     * the specified keystore.
+     * This method traverses the list of registered security {@link
+     * Provider providers}, starting with the most preferred Provider.
+     * For each {@link KeyStoreSpi} implementation supported by a
+     * Provider, it invokes the {@link
+     * KeyStoreSpi#engineProbe(InputStream) engineProbe} method to
+     * determine if it supports the specified keystore.
       * A new KeyStore object is returned that encapsulates the KeyStoreSpi
       * implementation from the first Provider that supports the 
specified file.
       *


From weijun.wang at oracle.com  Tue Feb 10 00:54:36 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Tue, 10 Feb 2015 08:54:36 +0800
Subject: JDK 9 RFR of JDK-8069277: Doclint regression in
	java/security/KeyStore.java
In-Reply-To: <54D950C5.1020906@oracle.com>
References: <54D950C5.1020906@oracle.com>
Message-ID: <879D34FA-00C5-4353-9913-C01A43D04648@oracle.com>

Should the "providers" link in the 2nd method also be "linkplain"?

--Max

> On Feb 10, 2015, at 08:28, Joseph D. Darcy <Joe.Darcy at oracle.com> wrote:
> 
> Hello,
> 
> As the final purge of doclint warnings from the java.base module approaches, please review the changes for
> 
>    JDK-8069277: Doclint regression in java/security/KeyStore.java
>    http://cr.openjdk.java.net/~darcy/8069277.0/
> 
> Patch below.
> 
> Thanks,
> 
> -Joe
> 
> --- old/src/java.base/share/classes/java/security/KeyStore.java 2015-02-09 16:25:01.853908872 -0800
> +++ new/src/java.base/share/classes/java/security/KeyStore.java 2015-02-09 16:25:01.529912945 -0800
> @@ -1618,11 +1618,13 @@
>      * integrity check.
>      *
>      * <p>
> -     * This method traverses the list of registered security {@link Providers},
> -     * starting with the most preferred Provider.
> -     * For each {@link KeyStoreSpi} implementation supported by a Provider,
> -     * it invokes the {@link engineProbe} method to determine if it supports
> -     * the specified keystore.
> +     * This method traverses the list of registered security
> +     * {@linkplain Provider providers}, starting with the most
> +     * preferred Provider.
> +     * For each {@link KeyStoreSpi} implementation supported by a
> +     * Provider, it invokes the {@link
> +     * KeyStoreSpi#engineProbe(InputStream) engineProbe} method to
> +     * determine if it supports the specified keystore.
>      * A new KeyStore object is returned that encapsulates the KeyStoreSpi
>      * implementation from the first Provider that supports the specified file.
>      *
> @@ -1672,11 +1674,12 @@
>      * unlock the keystore data or perform an integrity check.
>      *
>      * <p>
> -     * This method traverses the list of registered security {@link Providers},
> -     * starting with the most preferred Provider.
> -     * For each {@link KeyStoreSpi} implementation supported by a Provider,
> -     * it invokes the {@link engineProbe} method to determine if it supports
> -     * the specified keystore.
> +     * This method traverses the list of registered security {@link
> +     * Provider providers}, starting with the most preferred Provider.
> +     * For each {@link KeyStoreSpi} implementation supported by a
> +     * Provider, it invokes the {@link
> +     * KeyStoreSpi#engineProbe(InputStream) engineProbe} method to
> +     * determine if it supports the specified keystore.
>      * A new KeyStore object is returned that encapsulates the KeyStoreSpi
>      * implementation from the first Provider that supports the specified file.
>      *
> 


From joe.darcy at oracle.com  Tue Feb 10 01:25:01 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 09 Feb 2015 17:25:01 -0800
Subject: JDK 9 RFR of JDK-8069277: Doclint regression in
	java/security/KeyStore.java
In-Reply-To: <879D34FA-00C5-4353-9913-C01A43D04648@oracle.com>
References: <54D950C5.1020906@oracle.com>
	<879D34FA-00C5-4353-9913-C01A43D04648@oracle.com>
Message-ID: <54D95DED.2020206@oracle.com>

Hi Max,

Yes; both should be "linkplain" -- I'll push with that fix.

Thanks,

-Joe

On 2/9/2015 4:54 PM, Wang Weijun wrote:
> Should the "providers" link in the 2nd method also be "linkplain"?
>
> --Max
>
>> On Feb 10, 2015, at 08:28, Joseph D. Darcy <Joe.Darcy at oracle.com> wrote:
>>
>> Hello,
>>
>> As the final purge of doclint warnings from the java.base module approaches, please review the changes for
>>
>>     JDK-8069277: Doclint regression in java/security/KeyStore.java
>>     http://cr.openjdk.java.net/~darcy/8069277.0/
>>
>> Patch below.
>>
>> Thanks,
>>
>> -Joe
>>
>> --- old/src/java.base/share/classes/java/security/KeyStore.java 2015-02-09 16:25:01.853908872 -0800
>> +++ new/src/java.base/share/classes/java/security/KeyStore.java 2015-02-09 16:25:01.529912945 -0800
>> @@ -1618,11 +1618,13 @@
>>       * integrity check.
>>       *
>>       * <p>
>> -     * This method traverses the list of registered security {@link Providers},
>> -     * starting with the most preferred Provider.
>> -     * For each {@link KeyStoreSpi} implementation supported by a Provider,
>> -     * it invokes the {@link engineProbe} method to determine if it supports
>> -     * the specified keystore.
>> +     * This method traverses the list of registered security
>> +     * {@linkplain Provider providers}, starting with the most
>> +     * preferred Provider.
>> +     * For each {@link KeyStoreSpi} implementation supported by a
>> +     * Provider, it invokes the {@link
>> +     * KeyStoreSpi#engineProbe(InputStream) engineProbe} method to
>> +     * determine if it supports the specified keystore.
>>       * A new KeyStore object is returned that encapsulates the KeyStoreSpi
>>       * implementation from the first Provider that supports the specified file.
>>       *
>> @@ -1672,11 +1674,12 @@
>>       * unlock the keystore data or perform an integrity check.
>>       *
>>       * <p>
>> -     * This method traverses the list of registered security {@link Providers},
>> -     * starting with the most preferred Provider.
>> -     * For each {@link KeyStoreSpi} implementation supported by a Provider,
>> -     * it invokes the {@link engineProbe} method to determine if it supports
>> -     * the specified keystore.
>> +     * This method traverses the list of registered security {@link
>> +     * Provider providers}, starting with the most preferred Provider.
>> +     * For each {@link KeyStoreSpi} implementation supported by a
>> +     * Provider, it invokes the {@link
>> +     * KeyStoreSpi#engineProbe(InputStream) engineProbe} method to
>> +     * determine if it supports the specified keystore.
>>       * A new KeyStore object is returned that encapsulates the KeyStoreSpi
>>       * implementation from the first Provider that supports the specified file.
>>       *
>>


From xuelei.fan at oracle.com  Tue Feb 10 01:59:25 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 10 Feb 2015 09:59:25 +0800
Subject: RFR: 8065553: Failed Java web start via IPv6 (Java7u71 or later)
In-Reply-To: <54C909E6.8080206@oracle.com>
References: <54C909E6.8080206@oracle.com>
Message-ID: <54D965FD.7030209@oracle.com>

Hi Rob,

Sorry, I missed this review request.  The change looks fine to me,
except a minor coding style comment.

 159            InetAddress.getByName(ipAddress)))
 160       {

Would you mind join two lines together?  We normally don't use single
line "{"".

- 159            InetAddress.getByName(ipAddress)))
- 160       {
+ 159            InetAddress.getByName(ipAddress))) {

Please add a "noreg-" tag if no plan to add a new regression test.

Thanks,
Xuelei

On 1/29/2015 12:10 AM, Rob McKenna wrote:
> Hi folks,
> 
> There is a problem in sun/security/util/HostnameChecker.java matchIP
> method. When comparing an ipv6 address with its abbreviated counterpart
> the comparison will fail. I'm open to a more efficient way of comparing
> these addresses (perhaps a utility method to abbreviate an ipv6 string)
> but this seems to do the job.
> 
> http://cr.openjdk.java.net/~robm/8065553/webrev.01/
> 
> (btw, though this is a security component, it does seem to have a strong
> networking slant, so feel free to redirect me to net-dev)
> 
>     -Rob
> 
> 
> 


From rob.mckenna at oracle.com  Tue Feb 10 02:30:00 2015
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 10 Feb 2015 02:30:00 +0000
Subject: RFR: 8065553: Failed Java web start via IPv6 (Java7u71 or later)
In-Reply-To: <54D965FD.7030209@oracle.com>
References: <54C909E6.8080206@oracle.com> <54D965FD.7030209@oracle.com>
Message-ID: <54D96D28.3060905@oracle.com>

Thanks Xuelei, will do.

     -Rob

On 10/02/15 01:59, Xuelei Fan wrote:
> Hi Rob,
>
> Sorry, I missed this review request.  The change looks fine to me,
> except a minor coding style comment.
>
>   159            InetAddress.getByName(ipAddress)))
>   160       {
>
> Would you mind join two lines together?  We normally don't use single
> line "{"".
>
> - 159            InetAddress.getByName(ipAddress)))
> - 160       {
> + 159            InetAddress.getByName(ipAddress))) {
>
> Please add a "noreg-" tag if no plan to add a new regression test.
>
> Thanks,
> Xuelei
>
> On 1/29/2015 12:10 AM, Rob McKenna wrote:
>> Hi folks,
>>
>> There is a problem in sun/security/util/HostnameChecker.java matchIP
>> method. When comparing an ipv6 address with its abbreviated counterpart
>> the comparison will fail. I'm open to a more efficient way of comparing
>> these addresses (perhaps a utility method to abbreviate an ipv6 string)
>> but this seems to do the job.
>>
>> http://cr.openjdk.java.net/~robm/8065553/webrev.01/
>>
>> (btw, though this is a security component, it does seem to have a strong
>> networking slant, so feel free to redirect me to net-dev)
>>
>>      -Rob
>>
>>
>>


From zaiyao.liu at oracle.com  Tue Feb 10 07:46:40 2015
From: zaiyao.liu at oracle.com (zaiyao liu)
Date: Tue, 10 Feb 2015 15:46:40 +0800
Subject: [JDK-9] RFR: 8050371: MessageDigest tests
Message-ID: <54D9B760.20801@oracle.com>

Hi all,

Please help to review those 2 new tests to be added for MessageDigest, 
New tests are added to address following:

- Fixed length hash value is returned with different data inputs
- Same hash value is returned with different update and digest methods

JDK issue: https://bugs.openjdk.java.net/browse/JDK-8050371
Webrev:    http://cr.openjdk.java.net/~zailiu/8050371/webrev/

Thanks

Kevin

From jaroslav.bachorik at oracle.com  Wed Feb 11 16:10:03 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 11 Feb 2015 17:10:03 +0100
Subject: RFR 8072932: Test fails with java.security.AccessControlException:
	access denied ("java.security.SecurityPermission" "getDomainCombiner")
Message-ID: <54DB7EDB.3040506@oracle.com>

Please, review the following simple change.

Issue : https://bugs.openjdk.java.net/browse/JDK-8072932
Webrev: http://cr.openjdk.java.net/~jbachorik/8072932/webrev.00

This patch is about replacing the 
j.s.AccessControlContext.getDomainCombiner() with the package-private 
version j.s.AccessControlContext.getCombiner() to prevent the 
unnecessary privilege check done by the public getDomainCombiner() method.

Thanks,

-JB-

From jason.uh at oracle.com  Wed Feb 11 23:18:03 2015
From: jason.uh at oracle.com (Jason Uh)
Date: Wed, 11 Feb 2015 15:18:03 -0800
Subject: [9] RFR: 8042967: Add variant of DSA Signature algorithms that
	do not ASN.1 encode the signature bytes
In-Reply-To: <54CC0350.8000407@oracle.com>
References: <54C1B5F3.1010000@oracle.com>
	<20150126041521.0EF23D03BA@aojmv0009>	<54C6C2E1.1080407@oracle.com>	<201501272240.t0RMe45G005679@userp2020.oracle.com>	<54CA5154.6040302@oracle.com>
	<54CA9B08.4050403@oracle.com>	<201501292356.t0TNugUq021123@userp2020.oracle.com>
	<54CC0350.8000407@oracle.com>
Message-ID: <54DBE32B.1030702@oracle.com>

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 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, Jason Uh wrote:
>>> 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:
>>>
>>>   <digest>with<encryption>in<format>Format
>>>
>>> For example:
>>>
>>>   SHA1withDSAinP1363Format
>>>   SHA1withECDSAinP1363Format
>>
>> Hmm... hadn't gotten that far.
>>
>> I think that would work, but its not quite right as in this case its
>> about format, but might be about some other twiddle ( say endianess)
>> for other specifications.  If would be nice if the convention applied
>> to more than ECDSA and DSA.  I'm not opposed to the proposal though.
>>
>> My counter proposal would be for <algorithm>[/<specification>] as the
>> naming convention.  With the general contract that all implementations
>> of <algorithm> share the same general math at least for KeyAgreement
>> and Signature but may not share the same concrete representations or
>> encodings (e.g. there's difference in the encoding of the shared
>> secret output from DH for TLS vs pretty much everything else - has to
>> do with the integer to octet string conversion).  Again, not opposed
>> to the naming convention you suggested, just trying to think in meta
>> terms.
>>
>> Mike
>>
>>
>>
>>
>>
>>> The intent is to reduce potential confusion with the extended
>>> algorithm Strings specifying MGF functions
>>> (<digest>with<encryption>and<mgf>) by using the word "in" for
>>> conjunction and to append "Format" to the format name.
>>>
>>> Would you be ok with this solution?
>>>
>>> Thanks,
>>> Jason
>>>
>>> On 1/29/15 7:27 AM, Sean Mullan wrote:
>>>> On 01/27/2015 05:40 PM, Michael StJohns wrote:
>>>>> So what I'm concerned with is surprise.  I'm also concerned with
>>>>> "default signature formats" from new providers.  Right now, I know if
>>>>> I ask for ECDSA, the output of Signature will be in a very specific
>>>>> format, and the math will match what's in FIPS 186-4, X9.62 and SECG.
>>>>> I'm really uncomfortable about changing that.  I think the algorithm
>>>>> name should map to one specific suite of math and input/output
>>>>> formats.
>>>>
>>>> Yes, your argument makes sense, and we will change the fix to use new
>>>> algorithm Strings that specify the P1363 format. Jason will be
>>>> following
>>>> up with more details on that.
>>>>
>>>> Thanks for weighing in on this issue and spending the time to explain
>>>> your concerns.
>>>>
>>>> --Sean
>>
>>
>

From xuelei.fan at oracle.com  Wed Feb 11 23:42:45 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 12 Feb 2015 07:42:45 +0800
Subject: [9] RFR: 8042967: Add variant of DSA Signature algorithms that
	do not ASN.1 encode the signature bytes
In-Reply-To: <54DBE32B.1030702@oracle.com>
References: <54C1B5F3.1010000@oracle.com>	<20150126041521.0EF23D03BA@aojmv0009>	<54C6C2E1.1080407@oracle.com>	<201501272240.t0RMe45G005679@userp2020.oracle.com>	<54CA5154.6040302@oracle.com>	<54CA9B08.4050403@oracle.com>	<201501292356.t0TNugUq021123@userp2020.oracle.com>	<54CC0350.8000407@oracle.com>
	<54DBE32B.1030702@oracle.com>
Message-ID: <54DBE8F5.9040602@oracle.com>

I have not read the update.  Would you please also update:
    sun/security/util/DisabledAlgorithmConstraints.java

Which uses the algorithm format.

   // <digest>with<encryption>and<mgf>
+  // <digest>with<encryption>in<format>
   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, 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 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, Jason Uh wrote:
>>>> 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:
>>>>
>>>>   <digest>with<encryption>in<format>Format
>>>>
>>>> For example:
>>>>
>>>>   SHA1withDSAinP1363Format
>>>>   SHA1withECDSAinP1363Format
>>>
>>> Hmm... hadn't gotten that far.
>>>
>>> I think that would work, but its not quite right as in this case its
>>> about format, but might be about some other twiddle ( say endianess)
>>> for other specifications.  If would be nice if the convention applied
>>> to more than ECDSA and DSA.  I'm not opposed to the proposal though.
>>>
>>> My counter proposal would be for <algorithm>[/<specification>] as the
>>> naming convention.  With the general contract that all implementations
>>> of <algorithm> share the same general math at least for KeyAgreement
>>> and Signature but may not share the same concrete representations or
>>> encodings (e.g. there's difference in the encoding of the shared
>>> secret output from DH for TLS vs pretty much everything else - has to
>>> do with the integer to octet string conversion).  Again, not opposed
>>> to the naming convention you suggested, just trying to think in meta
>>> terms.
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>>
>>>> The intent is to reduce potential confusion with the extended
>>>> algorithm Strings specifying MGF functions
>>>> (<digest>with<encryption>and<mgf>) by using the word "in" for
>>>> conjunction and to append "Format" to the format name.
>>>>
>>>> Would you be ok with this solution?
>>>>
>>>> Thanks,
>>>> Jason
>>>>
>>>> On 1/29/15 7:27 AM, Sean Mullan wrote:
>>>>> On 01/27/2015 05:40 PM, Michael StJohns wrote:
>>>>>> So what I'm concerned with is surprise.  I'm also concerned with
>>>>>> "default signature formats" from new providers.  Right now, I know if
>>>>>> I ask for ECDSA, the output of Signature will be in a very specific
>>>>>> format, and the math will match what's in FIPS 186-4, X9.62 and SECG.
>>>>>> I'm really uncomfortable about changing that.  I think the algorithm
>>>>>> name should map to one specific suite of math and input/output
>>>>>> formats.
>>>>>
>>>>> Yes, your argument makes sense, and we will change the fix to use new
>>>>> algorithm Strings that specify the P1363 format. Jason will be
>>>>> following
>>>>> up with more details on that.
>>>>>
>>>>> Thanks for weighing in on this issue and spending the time to explain
>>>>> your concerns.
>>>>>
>>>>> --Sean
>>>
>>>
>>


From jason.uh at oracle.com  Thu Feb 12 00:16:09 2015
From: jason.uh at oracle.com (Jason Uh)
Date: Wed, 11 Feb 2015 16:16:09 -0800
Subject: [9] RFR: 8042967: Add variant of DSA Signature algorithms that
	do not ASN.1 encode the signature bytes
In-Reply-To: <54DBE8F5.9040602@oracle.com>
References: <54C1B5F3.1010000@oracle.com>	<20150126041521.0EF23D03BA@aojmv0009>	<54C6C2E1.1080407@oracle.com>	<201501272240.t0RMe45G005679@userp2020.oracle.com>	<54CA5154.6040302@oracle.com>	<54CA9B08.4050403@oracle.com>	<201501292356.t0TNugUq021123@userp2020.oracle.com>	<54CC0350.8000407@oracle.com>	<54DBE32B.1030702@oracle.com>
	<54DBE8F5.9040602@oracle.com>
Message-ID: <54DBF0C9.8050506@oracle.com>

Thanks for catching that. Here it is with your suggested change:
http://cr.openjdk.java.net/~juh/8042967/03/

Jason

On 02/11/2015 03:42 PM, Xuelei Fan wrote:
> I have not read the update.  Would you please also update:
>      sun/security/util/DisabledAlgorithmConstraints.java
>
> Which uses the algorithm format.
>
>     // <digest>with<encryption>and<mgf>
> +  // <digest>with<encryption>in<format>
>     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, 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 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, Jason Uh wrote:
>>>>> 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:
>>>>>
>>>>>    <digest>with<encryption>in<format>Format
>>>>>
>>>>> For example:
>>>>>
>>>>>    SHA1withDSAinP1363Format
>>>>>    SHA1withECDSAinP1363Format
>>>>
>>>> Hmm... hadn't gotten that far.
>>>>
>>>> I think that would work, but its not quite right as in this case its
>>>> about format, but might be about some other twiddle ( say endianess)
>>>> for other specifications.  If would be nice if the convention applied
>>>> to more than ECDSA and DSA.  I'm not opposed to the proposal though.
>>>>
>>>> My counter proposal would be for <algorithm>[/<specification>] as the
>>>> naming convention.  With the general contract that all implementations
>>>> of <algorithm> share the same general math at least for KeyAgreement
>>>> and Signature but may not share the same concrete representations or
>>>> encodings (e.g. there's difference in the encoding of the shared
>>>> secret output from DH for TLS vs pretty much everything else - has to
>>>> do with the integer to octet string conversion).  Again, not opposed
>>>> to the naming convention you suggested, just trying to think in meta
>>>> terms.
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> The intent is to reduce potential confusion with the extended
>>>>> algorithm Strings specifying MGF functions
>>>>> (<digest>with<encryption>and<mgf>) by using the word "in" for
>>>>> conjunction and to append "Format" to the format name.
>>>>>
>>>>> Would you be ok with this solution?
>>>>>
>>>>> Thanks,
>>>>> Jason
>>>>>
>>>>> On 1/29/15 7:27 AM, Sean Mullan wrote:
>>>>>> On 01/27/2015 05:40 PM, Michael StJohns wrote:
>>>>>>> So what I'm concerned with is surprise.  I'm also concerned with
>>>>>>> "default signature formats" from new providers.  Right now, I know if
>>>>>>> I ask for ECDSA, the output of Signature will be in a very specific
>>>>>>> format, and the math will match what's in FIPS 186-4, X9.62 and SECG.
>>>>>>> I'm really uncomfortable about changing that.  I think the algorithm
>>>>>>> name should map to one specific suite of math and input/output
>>>>>>> formats.
>>>>>>
>>>>>> Yes, your argument makes sense, and we will change the fix to use new
>>>>>> algorithm Strings that specify the P1363 format. Jason will be
>>>>>> following
>>>>>> up with more details on that.
>>>>>>
>>>>>> Thanks for weighing in on this issue and spending the time to explain
>>>>>> your concerns.
>>>>>>
>>>>>> --Sean
>>>>
>>>>
>>>
>

From sean.mullan at oracle.com  Thu Feb 12 13:43:19 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 12 Feb 2015 08:43:19 -0500
Subject: RFR 8072932: Test fails with java.security.AccessControlException:
	access denied ("java.security.SecurityPermission" "getDomainCombiner")
In-Reply-To: <54DB7EDB.3040506@oracle.com>
References: <54DB7EDB.3040506@oracle.com>
Message-ID: <54DCADF7.1010107@oracle.com>

Looks fine to me. Can you add a noreg-trivial label to the bug?

--Sean

On 02/11/2015 11:10 AM, Jaroslav Bachorik wrote:
> Please, review the following simple change.
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8072932
> Webrev: http://cr.openjdk.java.net/~jbachorik/8072932/webrev.00
>
> This patch is about replacing the
> j.s.AccessControlContext.getDomainCombiner() with the package-private
> version j.s.AccessControlContext.getCombiner() to prevent the
> unnecessary privilege check done by the public getDomainCombiner() method.
>
> Thanks,
>
> -JB-

From anthony.scarpino at oracle.com  Fri Feb 13 00:03:06 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 12 Feb 2015 16:03:06 -0800
Subject: RFR 8022313: sun/security/pkcs11/rsa/TestKeyPairGenerator.java failed
	in aurora
Message-ID: <54DD3F3A.1060600@oracle.com>

Hi,

Please review the quick change that from my testing stops the 
intermittent failure of this test, which I believe is caused by it 
colliding with other concurrently running tests

http://cr.openjdk.java.net/~ascarpino/8022313/webrev/

thanks

Tony

From jason.uh at oracle.com  Fri Feb 13 00:05:40 2015
From: jason.uh at oracle.com (Jason Uh)
Date: Thu, 12 Feb 2015 16:05:40 -0800
Subject: [9] RFR: 8054037: Improve tracing for java.security.debug=certpath
Message-ID: <54DD3FD4.3000106@oracle.com>

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

From sean.mullan at oracle.com  Fri Feb 13 00:06:38 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 12 Feb 2015 19:06:38 -0500
Subject: RFR 8022313: sun/security/pkcs11/rsa/TestKeyPairGenerator.java
	failed in aurora
In-Reply-To: <54DD3F3A.1060600@oracle.com>
References: <54DD3F3A.1060600@oracle.com>
Message-ID: <54DD400E.1050706@oracle.com>

Looks good. Add noreg-self label to bug.

--Sean

On 02/12/2015 07:03 PM, Anthony Scarpino wrote:
> Hi,
>
> Please review the quick change that from my testing stops the
> intermittent failure of this test, which I believe is caused by it
> colliding with other concurrently running tests
>
> http://cr.openjdk.java.net/~ascarpino/8022313/webrev/
>
> thanks
>
> Tony

From david.holmes at oracle.com  Fri Feb 13 02:39:30 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 13 Feb 2015 12:39:30 +1000
Subject: RFR 8072932: Test fails with java.security.AccessControlException:
	access denied ("java.security.SecurityPermission" "getDomainCombiner")
In-Reply-To: <54DB7EDB.3040506@oracle.com>
References: <54DB7EDB.3040506@oracle.com>
Message-ID: <54DD63E2.4080002@oracle.com>

On 12/02/2015 2:10 AM, Jaroslav Bachorik wrote:
> Please, review the following simple change.
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8072932
> Webrev: http://cr.openjdk.java.net/~jbachorik/8072932/webrev.00
>
> This patch is about replacing the
> j.s.AccessControlContext.getDomainCombiner() with the package-private
> version j.s.AccessControlContext.getCombiner() to prevent the
> unnecessary privilege check done by the public getDomainCombiner() method.

Just wondering: would the original call succeed if placed in a doPrivileged?

David

> Thanks,
>
> -JB-

From sean.mullan at oracle.com  Fri Feb 13 19:43:37 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 13 Feb 2015 14:43:37 -0500
Subject: RFR 8072394: Performance improvement for X.509 certificate parsing
In-Reply-To: <54D0A628.3080404@redhat.com>
References: <54D0A628.3080404@redhat.com>
Message-ID: <54DE53E9.7010200@oracle.com>

This fix looks fine, but I am trying to remember why a Set/LinkedHashSet 
was used in the first place, it seem like an List/ArrayList would have 
been more suitable. Even though PolicyInformation is an internal class, 
it's probably better to not change that detail at this point unless we 
have a better reason.

Can you add a noreg-perf label to the bug?

--Sean

On 02/03/2015 05:42 AM, Florian Weimer wrote:
> The sun.security.x509.PolicyInformation constructor creates
> java.security.cert.PolicyQualifierInfo instances and adds them to a
> LinkedHashSet. PolicyQualifierInfo does not override hashCode(), so the
> default implementation based on System.identityHashCode() is used, which
> is rather slow.
>
> I addressed this by implementing an explicit, identity-based hashCode()
> using an atomic counter.  Another approach would be to replace the
> LinkedHashSet with a Set backed by an ArrayList.
>
>    <http://cr.openjdk.java.net/~fweimer/8072394/webrev.00/>
>
> Before the change, this particular call to Object#hashCode() accounted
> for 25% of all hits in hprof.
>
> My benchmark involved parsing 1,000,000 certificates from the Google
> certificate transparency log.  The benchmark times includes loading the
> DER-encoded certificates from an SQLite database.  They are quite noisy
> because the X.509 parsing code allocates heavily.
>
> R says this about this change (run time is measured in seconds):
>
>> old <- c(50.246, 51.237, 50.057, 49.611, 49.895, 49.268, 50.161,
> 49.992, 49.972, 50.380)
>> new <- c(50.386, 50.628, 49.496, 49.196, 49.581, 49.845, 50.009,
> 49.229, 48.138, 48.762)
>> t.test(old, new)
>
> 	Welch Two Sample t-test
>
> data:  old and new
> t = 1.9356, df = 16.015, p-value = 0.07077
> alternative hypothesis: true difference in means is not equal to 0
> 95 percent confidence interval:
>   -0.05278151  1.16258151
> sample estimates:
> mean of x mean of y
>    50.0819   49.5270
>
>
>

From fweimer at redhat.com  Fri Feb 13 20:16:22 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Fri, 13 Feb 2015 21:16:22 +0100
Subject: RFR 8072394: Performance improvement for X.509 certificate parsing
In-Reply-To: <54DE53E9.7010200@oracle.com>
References: <54D0A628.3080404@redhat.com> <54DE53E9.7010200@oracle.com>
Message-ID: <54DE5B96.9000704@redhat.com>

On 02/13/2015 08:43 PM, Sean Mullan wrote:
> This fix looks fine, but I am trying to remember why a Set/LinkedHashSet
> was used in the first place, it seem like an List/ArrayList would have
> been more suitable. Even though PolicyInformation is an internal class,
> it's probably better to not change that detail at this point unless we
> have a better reason.

I think the Set is part of the public API:

<http://docs.oracle.com/javase/8/docs/api/java/security/cert/PolicyNode.html#getPolicyQualifiers-->

RFC 5280 says this: ?A certificate policy OID MUST NOT appear more than
once in a certificate policies extension.? (Section 4.2.4.1)

Based on that, PolicyQualifierInfo should have implemented value-based
equals() and hashCode(), and the identity-based set is just a bug.  (But
the requirement I cited is a stronger requirement the Set would not
enforce.)

However, I think it's too late to fix this bug now.  That's why I just
added the identity counter.  If you want the behavioral change instead,
I can implement that as well.

> Can you add a noreg-perf label to the bug?

Done, perhaps prematurely.

-- 
Florian Weimer / Red Hat Product Security

From zaiyao.liu at oracle.com  Mon Feb 16 01:35:54 2015
From: zaiyao.liu at oracle.com (zaiyao liu)
Date: Mon, 16 Feb 2015 09:35:54 +0800
Subject: [JDK-9] RFR: 8048610 Implement regression tests for bug fixes in JCE
Message-ID: <54E1497A.40703@oracle.com>

Hi all,

Please help to review those 2 new tests to verify following 2 JDK bug 
fixes in JCE:

- JDK-4686632: InvalidKeyException.getMessage() returns null
- JDK-4901658: Can not produce a string from key's encoded byte[] 
consistently

JDK issue: https://bugs.openjdk.java.net/browse/JDK-8048610
Webrev: http://cr.openjdk.java.net/~zailiu/8048610/webrev/

Thanks

Kevin

From weijun.wang at oracle.com  Mon Feb 16 02:20:46 2015
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 16 Feb 2015 10:20:46 +0800
Subject: RFR 8073181: keytool -ext honored not working correctly
Message-ID: <54E153FE.4020807@oracle.com>

Hi All

Please review the fix at

     http://cr.openjdk.java.net/~weijun/8073181/webrev.00/

The old honored code have 2 problems:

1. type not read if bare name without critical suffix
2. extension not added if critical flag is not modified

Thanks
Max

From weijun.wang at oracle.com  Mon Feb 16 07:56:31 2015
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 16 Feb 2015 15:56:31 +0800
Subject: RFR 8073182: keytool may generate duplicate extensions
Message-ID: <54E1A2AF.3010203@oracle.com>

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 duplicate.

Existing test updated.

Thanks
Max

From sean.mullan at oracle.com  Mon Feb 16 18:22:06 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 16 Feb 2015 13:22:06 -0500
Subject: [9] RFR: 8042967: Add variant of DSA Signature algorithms that
	do not ASN.1 encode the signature bytes
In-Reply-To: <54DBE32B.1030702@oracle.com>
References: <54C1B5F3.1010000@oracle.com>
	<20150126041521.0EF23D03BA@aojmv0009>	<54C6C2E1.1080407@oracle.com>	<201501272240.t0RMe45G005679@userp2020.oracle.com>	<54CA5154.6040302@oracle.com>
	<54CA9B08.4050403@oracle.com>	<201501292356.t0TNugUq021123@userp2020.oracle.com>
	<54CC0350.8000407@oracle.com> <54DBE32B.1030702@oracle.com>
Message-ID: <54E2354E.7050101@oracle.com>

Hi Jason,

Here are my comments -

* General

- please open a corresponding issue to add these new algorithms to the 
"Standard Algorithm Names" and "Oracle Providers" security guides. File 
in the docs/guides component and add a "securitydocs" label. Please add 
a release-notes=yes label to the bug as well.

* DSA.java

- 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) 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 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, Jason Uh wrote:
>>>> 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:
>>>>
>>>>   <digest>with<encryption>in<format>Format
>>>>
>>>> For example:
>>>>
>>>>   SHA1withDSAinP1363Format
>>>>   SHA1withECDSAinP1363Format
>>>
>>> Hmm... hadn't gotten that far.
>>>
>>> I think that would work, but its not quite right as in this case its
>>> about format, but might be about some other twiddle ( say endianess)
>>> for other specifications.  If would be nice if the convention applied
>>> to more than ECDSA and DSA.  I'm not opposed to the proposal though.
>>>
>>> My counter proposal would be for <algorithm>[/<specification>] as the
>>> naming convention.  With the general contract that all implementations
>>> of <algorithm> share the same general math at least for KeyAgreement
>>> and Signature but may not share the same concrete representations or
>>> encodings (e.g. there's difference in the encoding of the shared
>>> secret output from DH for TLS vs pretty much everything else - has to
>>> do with the integer to octet string conversion).  Again, not opposed
>>> to the naming convention you suggested, just trying to think in meta
>>> terms.
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>>
>>>> The intent is to reduce potential confusion with the extended
>>>> algorithm Strings specifying MGF functions
>>>> (<digest>with<encryption>and<mgf>) by using the word "in" for
>>>> conjunction and to append "Format" to the format name.
>>>>
>>>> Would you be ok with this solution?
>>>>
>>>> Thanks,
>>>> Jason
>>>>
>>>> On 1/29/15 7:27 AM, Sean Mullan wrote:
>>>>> On 01/27/2015 05:40 PM, Michael StJohns wrote:
>>>>>> So what I'm concerned with is surprise.  I'm also concerned with
>>>>>> "default signature formats" from new providers.  Right now, I know if
>>>>>> I ask for ECDSA, the output of Signature will be in a very specific
>>>>>> format, and the math will match what's in FIPS 186-4, X9.62 and SECG.
>>>>>> I'm really uncomfortable about changing that.  I think the algorithm
>>>>>> name should map to one specific suite of math and input/output
>>>>>> formats.
>>>>>
>>>>> Yes, your argument makes sense, and we will change the fix to use new
>>>>> algorithm Strings that specify the P1363 format. Jason will be
>>>>> following
>>>>> up with more details on that.
>>>>>
>>>>> Thanks for weighing in on this issue and spending the time to explain
>>>>> your concerns.
>>>>>
>>>>> --Sean
>>>
>>>
>>

From jason.uh at oracle.com  Mon Feb 16 18:53:49 2015
From: jason.uh at oracle.com (Jason Uh)
Date: Mon, 16 Feb 2015 10:53:49 -0800
Subject: [9] RFR: 8042967: Add variant of DSA Signature algorithms that
	do not ASN.1 encode the signature bytes
In-Reply-To: <54E2354E.7050101@oracle.com>
References: <54C1B5F3.1010000@oracle.com>
	<20150126041521.0EF23D03BA@aojmv0009>	<54C6C2E1.1080407@oracle.com>	<201501272240.t0RMe45G005679@userp2020.oracle.com>	<54CA5154.6040302@oracle.com>
	<54CA9B08.4050403@oracle.com>	<201501292356.t0TNugUq021123@userp2020.oracle.com>
	<54CC0350.8000407@oracle.com> <54DBE32B.1030702@oracle.com>
	<54E2354E.7050101@oracle.com>
Message-ID: <54E23CBD.10204@oracle.com>

Thanks Sean.

Here it is with your suggested changes:
http://cr.openjdk.java.net/~juh/8042967/04/

Opened an issue to track the docs changes:
https://bugs.openjdk.java.net/browse/JDK-8073261

Jason


On 02/16/2015 10:22 AM, Sean Mullan wrote:
> Hi Jason,
>
> Here are my comments -
>
> * General
>
> - please open a corresponding issue to add these new algorithms to the
> "Standard Algorithm Names" and "Oracle Providers" security guides. File
> in the docs/guides component and add a "securitydocs" label. Please add
> a release-notes=yes label to the bug as well.
>
> * DSA.java
>
> - 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) 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 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, Jason Uh wrote:
>>>>> 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:
>>>>>
>>>>>   <digest>with<encryption>in<format>Format
>>>>>
>>>>> For example:
>>>>>
>>>>>   SHA1withDSAinP1363Format
>>>>>   SHA1withECDSAinP1363Format
>>>>
>>>> Hmm... hadn't gotten that far.
>>>>
>>>> I think that would work, but its not quite right as in this case its
>>>> about format, but might be about some other twiddle ( say endianess)
>>>> for other specifications.  If would be nice if the convention applied
>>>> to more than ECDSA and DSA.  I'm not opposed to the proposal though.
>>>>
>>>> My counter proposal would be for <algorithm>[/<specification>] as the
>>>> naming convention.  With the general contract that all implementations
>>>> of <algorithm> share the same general math at least for KeyAgreement
>>>> and Signature but may not share the same concrete representations or
>>>> encodings (e.g. there's difference in the encoding of the shared
>>>> secret output from DH for TLS vs pretty much everything else - has to
>>>> do with the integer to octet string conversion).  Again, not opposed
>>>> to the naming convention you suggested, just trying to think in meta
>>>> terms.
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> The intent is to reduce potential confusion with the extended
>>>>> algorithm Strings specifying MGF functions
>>>>> (<digest>with<encryption>and<mgf>) by using the word "in" for
>>>>> conjunction and to append "Format" to the format name.
>>>>>
>>>>> Would you be ok with this solution?
>>>>>
>>>>> Thanks,
>>>>> Jason
>>>>>
>>>>> On 1/29/15 7:27 AM, Sean Mullan wrote:
>>>>>> On 01/27/2015 05:40 PM, Michael StJohns wrote:
>>>>>>> So what I'm concerned with is surprise.  I'm also concerned with
>>>>>>> "default signature formats" from new providers.  Right now, I
>>>>>>> know if
>>>>>>> I ask for ECDSA, the output of Signature will be in a very specific
>>>>>>> format, and the math will match what's in FIPS 186-4, X9.62 and
>>>>>>> SECG.
>>>>>>> I'm really uncomfortable about changing that.  I think the algorithm
>>>>>>> name should map to one specific suite of math and input/output
>>>>>>> formats.
>>>>>>
>>>>>> Yes, your argument makes sense, and we will change the fix to use new
>>>>>> algorithm Strings that specify the P1363 format. Jason will be
>>>>>> following
>>>>>> up with more details on that.
>>>>>>
>>>>>> Thanks for weighing in on this issue and spending the time to explain
>>>>>> your concerns.
>>>>>>
>>>>>> --Sean
>>>>
>>>>
>>>

From jason.uh at oracle.com  Mon Feb 16 19:32:20 2015
From: jason.uh at oracle.com (Jason Uh)
Date: Mon, 16 Feb 2015 11:32:20 -0800
Subject: RFR 8073182: keytool may generate duplicate extensions
In-Reply-To: <54E1A2AF.3010203@oracle.com>
References: <54E1A2AF.3010203@oracle.com>
Message-ID: <54E245C4.5090408@oracle.com>

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 duplicate.
>
> Existing test updated.
>
> Thanks
> Max


From anthony.scarpino at oracle.com  Mon Feb 16 19:51:50 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Mon, 16 Feb 2015 11:51:50 -0800
Subject: RFR 8073113: sun/security/pkcs11/MessageDigest/TestCloning.java failed
	due to CloneNotSupportedException: SHA-256
Message-ID: <54E24A56.5080605@oracle.com>

I'd like a review for adding this TestCloning.java to the ProblemList.

This change is not because of a functional problem in Java, it's because 
testing continues to occur on unpatched Solaris 10 machines for this 
Solaris bug.  The test will continue to run on Solaris 11, where the 
problem doesn't exist so we are not missing test coverage. 
Additionally, this is only going to JDK8u because Solaris 10 is not 
supported in JDK9.

http://cr.openjdk.java.net/~ascarpino/8073113-8u/webrev/

Tony

From anthony.scarpino at oracle.com  Mon Feb 16 19:57:41 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Mon, 16 Feb 2015 11:57:41 -0800
Subject: RFR 8073113: sun/security/pkcs11/MessageDigest/TestCloning.java
	failed due to CloneNotSupportedException: SHA-256
In-Reply-To: <54E24A56.5080605@oracle.com>
References: <54E24A56.5080605@oracle.com>
Message-ID: <54E24BB5.4050706@oracle.com>

FYI, the bug number should be JDK-8043951.  The one I listed was the 
backport ID.  The link below is still valid


On 02/16/2015 11:51 AM, Anthony Scarpino wrote:
> I'd like a review for adding this TestCloning.java to the ProblemList.
>
> This change is not because of a functional problem in Java, it's because
> testing continues to occur on unpatched Solaris 10 machines for this
> Solaris bug.  The test will continue to run on Solaris 11, where the
> problem doesn't exist so we are not missing test coverage. Additionally,
> this is only going to JDK8u because Solaris 10 is not supported in JDK9.
>
> http://cr.openjdk.java.net/~ascarpino/8073113-8u/webrev/
>
> Tony



From anthony.scarpino at oracle.com  Mon Feb 16 21:11:31 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Mon, 16 Feb 2015 13:11:31 -0800
Subject: RFR: 8073108: GHASH Intrinsics
Message-ID: <54E25D03.7090705@oracle.com>

Hi,

I'm requesting a code review to intrinsify the GHASH operations for both 
x86 and SPARC platforms.  This greatly increases performance over 
software for AES/GCM crypto operations, details are in the bug.

The review is for two repos, hotspot and jdk:

http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/

http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/

thanks

Tony

From sean.mullan at oracle.com  Mon Feb 16 22:13:00 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 16 Feb 2015 17:13:00 -0500
Subject: RFR 8072394: Performance improvement for X.509 certificate parsing
In-Reply-To: <54DE5B96.9000704@redhat.com>
References: <54D0A628.3080404@redhat.com> <54DE53E9.7010200@oracle.com>
	<54DE5B96.9000704@redhat.com>
Message-ID: <54E26B6C.3040202@oracle.com>

On 02/13/2015 03:16 PM, Florian Weimer wrote:
> On 02/13/2015 08:43 PM, Sean Mullan wrote:
>> This fix looks fine, but I am trying to remember why a Set/LinkedHashSet
>> was used in the first place, it seem like an List/ArrayList would have
>> been more suitable. Even though PolicyInformation is an internal class,
>> it's probably better to not change that detail at this point unless we
>> have a better reason.
>
> I think the Set is part of the public API:
>
> <http://docs.oracle.com/javase/8/docs/api/java/security/cert/PolicyNode.html#getPolicyQualifiers-->
>
> RFC 5280 says this: ?A certificate policy OID MUST NOT appear more than
> once in a certificate policies extension.? (Section 4.2.4.1)

Ah, thanks for the reminder.

> Based on that, PolicyQualifierInfo should have implemented value-based
> equals() and hashCode(), and the identity-based set is just a bug.  (But
> the requirement I cited is a stronger requirement the Set would not
> enforce.)
>
> However, I think it's too late to fix this bug now.  That's why I just
> added the identity counter.  If you want the behavioral change instead,
> I can implement that as well.

Maybe it's not too late. This is not a commonly used class, and the 
compatibility risk is probably fairly low. If you code up the changes, I 
can file a CCC on your behalf.

--Sean

>
>> Can you add a noreg-perf label to the bug?
>
> Done, perhaps prematurely.
>

From sean.mullan at oracle.com  Mon Feb 16 22:48:48 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 16 Feb 2015 17:48:48 -0500
Subject: RFR 8073113: sun/security/pkcs11/MessageDigest/TestCloning.java
	failed due to CloneNotSupportedException: SHA-256
In-Reply-To: <54E24BB5.4050706@oracle.com>
References: <54E24A56.5080605@oracle.com> <54E24BB5.4050706@oracle.com>
Message-ID: <54E273D0.8050900@oracle.com>

On 02/16/2015 02:57 PM, Anthony Scarpino wrote:
> FYI, the bug number should be JDK-8043951.  The one I listed was the
> backport ID.  The link below is still valid

Normally, the bug in the comment above a problem list entry is the bug 
that remains open and still needs to be fixed for the problem entry to 
be removed, and you open a separate bug to add the entry to the problem 
list. So you should open a new bug (ex: add 
sun/security/pkcs11/MessageDigest/TestCloning.java to ProblemList) and 
leave 8043951 open.

--Sean

>
> On 02/16/2015 11:51 AM, Anthony Scarpino wrote:
>> I'd like a review for adding this TestCloning.java to the ProblemList.
>>
>> This change is not because of a functional problem in Java, it's because
>> testing continues to occur on unpatched Solaris 10 machines for this
>> Solaris bug.  The test will continue to run on Solaris 11, where the
>> problem doesn't exist so we are not missing test coverage. Additionally,
>> this is only going to JDK8u because Solaris 10 is not supported in JDK9.
>>
>> http://cr.openjdk.java.net/~ascarpino/8073113-8u/webrev/
>>
>> Tony
>
>

From anthony.scarpino at oracle.com  Mon Feb 16 23:32:29 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Mon, 16 Feb 2015 15:32:29 -0800
Subject: RFR 8073113: sun/security/pkcs11/MessageDigest/TestCloning.java
	failed due to CloneNotSupportedException: SHA-256
In-Reply-To: <54E273D0.8050900@oracle.com>
References: <54E24A56.5080605@oracle.com> <54E24BB5.4050706@oracle.com>
	<54E273D0.8050900@oracle.com>
Message-ID: <54E27E0D.9020703@oracle.com>

On 02/16/2015 02:48 PM, Sean Mullan wrote:
> On 02/16/2015 02:57 PM, Anthony Scarpino wrote:
>> FYI, the bug number should be JDK-8043951.  The one I listed was the
>> backport ID.  The link below is still valid
>
> Normally, the bug in the comment above a problem list entry is the bug
> that remains open and still needs to be fixed for the problem entry to
> be removed, and you open a separate bug to add the entry to the problem
> list. So you should open a new bug (ex: add
> sun/security/pkcs11/MessageDigest/TestCloning.java to ProblemList) and
> leave 8043951 open.
>
> --Sean
>

I understand what you're saying, but I'm not sure how keeping 8043951 
open will help given this is an infrastructure issue.  Once disabled, we 
will never know really when it's fixed from a product standpoint.

If we want the bug in the ProblemList to remain open, I would say 
putting the infrastructure bug number INTJDK-7613285 would be best.

Tony

>>
>> On 02/16/2015 11:51 AM, Anthony Scarpino wrote:
>>> I'd like a review for adding this TestCloning.java to the ProblemList.
>>>
>>> This change is not because of a functional problem in Java, it's because
>>> testing continues to occur on unpatched Solaris 10 machines for this
>>> Solaris bug.  The test will continue to run on Solaris 11, where the
>>> problem doesn't exist so we are not missing test coverage. Additionally,
>>> this is only going to JDK8u because Solaris 10 is not supported in JDK9.
>>>
>>> http://cr.openjdk.java.net/~ascarpino/8073113-8u/webrev/
>>>
>>> Tony
>>
>>


From david.holmes at oracle.com  Tue Feb 17 01:23:57 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Feb 2015 11:23:57 +1000
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E25D03.7090705@oracle.com>
References: <54E25D03.7090705@oracle.com>
Message-ID: <54E2982D.9020902@oracle.com>

Hi Tony,

Not a review as hotspot compiler folk need to review this.

On 17/02/2015 7:11 AM, Anthony Scarpino wrote:
> Hi,
>
> I'm requesting a code review to intrinsify the GHASH operations for both
> x86 and SPARC platforms.  This greatly increases performance over
> software for AES/GCM crypto operations, details are in the bug.

This may be normal for intrinsics but there seems to be a large amount 
of shared code being updated to support these platform specific 
enhancements. What happens on other platforms if the user sets 
UseGHASHIntrinsics? Shouldn't there be a guard against this in 
arguments.cpp?

Thanks,
David

> The review is for two repos, hotspot and jdk:
>
> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/
>
> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/
>
> thanks
>
> Tony

From vladimir.kozlov at oracle.com  Tue Feb 17 02:01:46 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 16 Feb 2015 18:01:46 -0800
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E2982D.9020902@oracle.com>
References: <54E25D03.7090705@oracle.com> <54E2982D.9020902@oracle.com>
Message-ID: <54E2A10A.6090007@oracle.com>

On 2/16/15 5:23 PM, David Holmes wrote:
> Hi Tony,
>
> Not a review as hotspot compiler folk need to review this.
>
> On 17/02/2015 7:11 AM, Anthony Scarpino wrote:
>> Hi,
>>
>> I'm requesting a code review to intrinsify the GHASH operations for both
>> x86 and SPARC platforms.  This greatly increases performance over
>> software for AES/GCM crypto operations, details are in the bug.
>
> This may be normal for intrinsics but there seems to be a large amount
> of shared code being updated to support these platform specific
> enhancements. What happens on other platforms if the user sets
> UseGHASHIntrinsics? Shouldn't there be a guard against this in
> arguments.cpp?

Code in vm_version_<arch>.cpp does the check. vm_version_sparc.cpp and 
vm_version_x86.cpp do that.

Tony, please, fix other vm_version_<arch>.cpp files (including closed) 
to set corresponding flag to false. See UseAES as example.

Also code in vm_version_sparc.cpp should be similar to one in 
vm_version_x86.cpp. Something like:

   // GHASH/GCM intrinsics
   if (has_vis3() && (UseVIS > 2)) {
     if (FLAG_IS_DEFAULT(UseGHASHIntrinsics)) {
       UseGHASHIntrinsics = true;
     }
   } else if (UseGHASHIntrinsics) {
     if (!FLAG_IS_DEFAULT(UseGHASHIntrinsics))
       warning("GHASH intrinsics require VIS3 insructions support. 
Intriniscs will be disabled");
     FLAG_SET_DEFAULT(UseGHASHIntrinsics, false);
   }

There is #ifdef _WIN64 in stubGenerator_x86_32.cpp. It is not needed 
since it is 32-bit code.

I see you switched off -DcheckOutput=false for GCM testing and return 
from compareArrays() after length compare. Is it because it can't be 
done or you did not have time to add needed code?

Otherwise Hotspot code looks good.

Thanks,
Vladimir

>
> Thanks,
> David
>
>> The review is for two repos, hotspot and jdk:
>>
>> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/
>>
>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/
>>
>> thanks
>>
>> Tony

From john.r.rose at oracle.com  Tue Feb 17 02:47:14 2015
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 16 Feb 2015 18:47:14 -0800
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E25D03.7090705@oracle.com>
References: <54E25D03.7090705@oracle.com>
Message-ID: <31E530B4-B880-4630-A830-663145817AC1@oracle.com>

Cool stuff.  I'm glad to see SPARC xmulx getting some play.

This is not a review, but I have a small and a big comment.

You don't need the argument vmIntrinsics::ID id unless you are going to do something with it, such as expand one of a family of intrinsics covered by the same LCK::inline* routine.

You probably don't have enough parameter verification on the inputs to processBlocks.  A robust range check for a subsequence indexing operation requires three comparison operations, not just one.  The Java code uses getLong which includes additional range checks, but your intrinsic replacement code might not do that correctly; in any case, it's better to have all the subsequence range checks in one place, and in Java code.  (Oh, and watch out for 32-bit integer overflow:  That causes surprises sometimes, when a value that is too large wraps to negative, and then can seem to be in range relative to a <= check.)

In fact, I don't believe the existing parameter verification is very helpful at all:

   if (inLen - inOfs > in.length)  throw...

This appears to allow a ridiculously large inLen as long as inOfs is also ridiculously large.  All of the "heavy lifting" is done by intrinisic array range checks triggered by getLong, and those are the checks that the assembly code does *not* do.

? John

P.S.  We should have a library API to do these parameter checks.  See:
  https://bugs.openjdk.java.net/browse/JDK-8042997#comment-13610181

On Feb 16, 2015, at 1:11 PM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
> 
> Hi,
> 
> I'm requesting a code review to intrinsify the GHASH operations for both x86 and SPARC platforms.  This greatly increases performance over software for AES/GCM crypto operations, details are in the bug.
> 
> The review is for two repos, hotspot and jdk:
> 
> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/
> 
> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/
> 
> thanks
> 
> Tony


From fweimer at redhat.com  Tue Feb 17 08:57:46 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 17 Feb 2015 09:57:46 +0100
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E25D03.7090705@oracle.com>
References: <54E25D03.7090705@oracle.com>
Message-ID: <54E3028A.7040102@redhat.com>

On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/

I think the ?state? field in GHASH should be final.  Is C2 able to
eliminate the array bounds checks?  (Although it's not in the inner loop
and thus probably not relevant for performance.)

The comment on processBlock(byte[], int, int) is confusing.  I don't
understand what it is trying to say.

-- 
Florian Weimer / Red Hat Product Security

From fweimer at redhat.com  Tue Feb 17 10:59:17 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 17 Feb 2015 11:59:17 +0100
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E25D03.7090705@oracle.com>
References: <54E25D03.7090705@oracle.com>
Message-ID: <54E31F05.2020805@redhat.com>

On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
> Hi,
> 
> I'm requesting a code review to intrinsify the GHASH operations for both
> x86 and SPARC platforms.  This greatly increases performance over
> software for AES/GCM crypto operations, details are in the bug.
> 
> The review is for two repos, hotspot and jdk:
> 
> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/

Sorry for double-posting.

I looked at generate_ghash_processBlocks() and wonder if the loop needs
to be split to introduce occasional safepoints.  The TLS record size
should limit the number bytes per invocation to 16000, so perhaps this
isn't issue for the current application.

-- 
Florian Weimer / Red Hat Product Security

From sean.mullan at oracle.com  Tue Feb 17 12:32:35 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 17 Feb 2015 07:32:35 -0500
Subject: RFR 8073113: sun/security/pkcs11/MessageDigest/TestCloning.java
	failed due to CloneNotSupportedException: SHA-256
In-Reply-To: <54E27E0D.9020703@oracle.com>
References: <54E24A56.5080605@oracle.com> <54E24BB5.4050706@oracle.com>
	<54E273D0.8050900@oracle.com> <54E27E0D.9020703@oracle.com>
Message-ID: <54E334E3.7080309@oracle.com>

On 02/16/2015 06:32 PM, Anthony Scarpino wrote:
> On 02/16/2015 02:48 PM, Sean Mullan wrote:
>> On 02/16/2015 02:57 PM, Anthony Scarpino wrote:
>>> FYI, the bug number should be JDK-8043951.  The one I listed was the
>>> backport ID.  The link below is still valid
>>
>> Normally, the bug in the comment above a problem list entry is the bug
>> that remains open and still needs to be fixed for the problem entry to
>> be removed, and you open a separate bug to add the entry to the problem
>> list. So you should open a new bug (ex: add
>> sun/security/pkcs11/MessageDigest/TestCloning.java to ProblemList) and
>> leave 8043951 open.
>>
>> --Sean
>>
>
> I understand what you're saying, but I'm not sure how keeping 8043951
> open will help given this is an infrastructure issue.  Once disabled, we
> will never know really when it's fixed from a product standpoint.

Ok, what you are basically saying is that this ProblemList entry should 
never be removed. That is probably not a good usage of ProblemList.

>
> If we want the bug in the ProblemList to remain open, I would say
> putting the infrastructure bug number INTJDK-7613285 would be best.

That bug is non-public though (Oracle-specific).

Maybe it makes more sense to change the test to check if the os.name is 
Solaris and the os.version is < 11, and not continue instead of adding a 
ProblemList entry.

--Sean

>
> Tony
>
>>>
>>> On 02/16/2015 11:51 AM, Anthony Scarpino wrote:
>>>> I'd like a review for adding this TestCloning.java to the ProblemList.
>>>>
>>>> This change is not because of a functional problem in Java, it's
>>>> because
>>>> testing continues to occur on unpatched Solaris 10 machines for this
>>>> Solaris bug.  The test will continue to run on Solaris 11, where the
>>>> problem doesn't exist so we are not missing test coverage.
>>>> Additionally,
>>>> this is only going to JDK8u because Solaris 10 is not supported in
>>>> JDK9.
>>>>
>>>> http://cr.openjdk.java.net/~ascarpino/8073113-8u/webrev/
>>>>
>>>> Tony
>>>
>>>
>

From fweimer at redhat.com  Tue Feb 17 14:30:30 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 17 Feb 2015 15:30:30 +0100
Subject: RFR 8072394: java.security.cert.PolicyQualifierInfo needs value-based
	equality
In-Reply-To: <54E26B6C.3040202@oracle.com>
References: <54D0A628.3080404@redhat.com> <54DE53E9.7010200@oracle.com>
	<54DE5B96.9000704@redhat.com> <54E26B6C.3040202@oracle.com>
Message-ID: <54E35086.7090408@redhat.com>

On 02/16/2015 11:13 PM, Sean Mullan wrote:

>> Based on that, PolicyQualifierInfo should have implemented value-based
>> equals() and hashCode(), and the identity-based set is just a bug.  (But
>> the requirement I cited is a stronger requirement the Set would not
>> enforce.)
>>
>> However, I think it's too late to fix this bug now.  That's why I just
>> added the identity counter.  If you want the behavioral change instead,
>> I can implement that as well.
> 
> Maybe it's not too late. This is not a commonly used class, and the
> compatibility risk is probably fairly low. If you code up the changes, I
> can file a CCC on your behalf.

Updated webrev: <http://cr.openjdk.java.net/~fweimer/8072394/webrev.01/>

I sneaked in a memory model fix to make the class really immutable, and
simplified the constructor a bit (mEncoded is already a copy, there is
no need for further copying).

There's also a new tested, mostly copied from the existing
GetPolicyQualifiers test.  (I didn't want to edit the existing test be
cause that sometimes causes trouble.)  The DER values were generated by
pyasn1 and verified using Peter Gutmann's dumpasn1.

I couldn't find any other tests for PolicyQualifierInfo, but you may
have closed tests that need adjusting.

-- 
Florian Weimer / Red Hat Product Security

From anthony.scarpino at oracle.com  Tue Feb 17 18:31:37 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Tue, 17 Feb 2015 10:31:37 -0800
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E2A10A.6090007@oracle.com>
References: <54E25D03.7090705@oracle.com> <54E2982D.9020902@oracle.com>
	<54E2A10A.6090007@oracle.com>
Message-ID: <54E38909.5070800@oracle.com>

On 02/16/2015 06:01 PM, Vladimir Kozlov wrote:
> On 2/16/15 5:23 PM, David Holmes wrote:
>> Hi Tony,
>>
>> Not a review as hotspot compiler folk need to review this.
>>
>> On 17/02/2015 7:11 AM, Anthony Scarpino wrote:
>>> Hi,
>>>
>>> I'm requesting a code review to intrinsify the GHASH operations for both
>>> x86 and SPARC platforms.  This greatly increases performance over
>>> software for AES/GCM crypto operations, details are in the bug.
>>
>> This may be normal for intrinsics but there seems to be a large amount
>> of shared code being updated to support these platform specific
>> enhancements. What happens on other platforms if the user sets
>> UseGHASHIntrinsics? Shouldn't there be a guard against this in
>> arguments.cpp?
>
> Code in vm_version_<arch>.cpp does the check. vm_version_sparc.cpp and
> vm_version_x86.cpp do that.
>
> Tony, please, fix other vm_version_<arch>.cpp files (including closed)
> to set corresponding flag to false. See UseAES as example.

Ok.. thanks Dave & Vladimir for bring that up.. I fix that..


> Also code in vm_version_sparc.cpp should be similar to one in
> vm_version_x86.cpp. Something like:
>
>    // GHASH/GCM intrinsics
>    if (has_vis3() && (UseVIS > 2)) {
>      if (FLAG_IS_DEFAULT(UseGHASHIntrinsics)) {
>        UseGHASHIntrinsics = true;
>      }
>    } else if (UseGHASHIntrinsics) {
>      if (!FLAG_IS_DEFAULT(UseGHASHIntrinsics))
>        warning("GHASH intrinsics require VIS3 insructions support.
> Intriniscs will be disabled");
>      FLAG_SET_DEFAULT(UseGHASHIntrinsics, false);
>    }
>

Sure..

> There is #ifdef _WIN64 in stubGenerator_x86_32.cpp. It is not needed
> since it is 32-bit code.

Sure.. Do I still need to save the xmm6 and xmm7 on 32bit code, or is 
all of the register saving only for Windows 64bit?

>
> I see you switched off -DcheckOutput=false for GCM testing and return
> from compareArrays() after length compare. Is it because it can't be
> done or you did not have time to add needed code?

I'll have to double check, but I believe -DcheckOutput can be turned 
back on.  I suspect I never updated the @run lines after I changed 
compareArrays()

> Otherwise Hotspot code looks good.
>
> Thanks,
> Vladimir
>
>>
>> Thanks,
>> David
>>
>>> The review is for two repos, hotspot and jdk:
>>>
>>> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/
>>>
>>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/
>>>
>>> thanks
>>>
>>> Tony


From sean.mullan at oracle.com  Tue Feb 17 18:36:26 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 17 Feb 2015 13:36:26 -0500
Subject: [9] RFR: 8042967: Add variant of DSA Signature algorithms that
	do not ASN.1 encode the signature bytes
In-Reply-To: <54E23CBD.10204@oracle.com>
References: <54C1B5F3.1010000@oracle.com>
	<20150126041521.0EF23D03BA@aojmv0009>	<54C6C2E1.1080407@oracle.com>	<201501272240.t0RMe45G005679@userp2020.oracle.com>	<54CA5154.6040302@oracle.com>
	<54CA9B08.4050403@oracle.com>	<201501292356.t0TNugUq021123@userp2020.oracle.com>
	<54CC0350.8000407@oracle.com> <54DBE32B.1030702@oracle.com>
	<54E2354E.7050101@oracle.com> <54E23CBD.10204@oracle.com>
Message-ID: <54E38A2A.4010603@oracle.com>

Looks good.

--Sean

On 02/16/2015 01:53 PM, Jason Uh wrote:
> Thanks Sean.
>
> Here it is with your suggested changes:
> http://cr.openjdk.java.net/~juh/8042967/04/
>
> Opened an issue to track the docs changes:
> https://bugs.openjdk.java.net/browse/JDK-8073261
>
> Jason
>
>
> On 02/16/2015 10:22 AM, Sean Mullan wrote:
>> Hi Jason,
>>
>> Here are my comments -
>>
>> * General
>>
>> - please open a corresponding issue to add these new algorithms to the
>> "Standard Algorithm Names" and "Oracle Providers" security guides. File
>> in the docs/guides component and add a "securitydocs" label. Please add
>> a release-notes=yes label to the bug as well.
>>
>> * DSA.java
>>
>> - 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) 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 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, Jason Uh wrote:
>>>>>> 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:
>>>>>>
>>>>>>   <digest>with<encryption>in<format>Format
>>>>>>
>>>>>> For example:
>>>>>>
>>>>>>   SHA1withDSAinP1363Format
>>>>>>   SHA1withECDSAinP1363Format
>>>>>
>>>>> Hmm... hadn't gotten that far.
>>>>>
>>>>> I think that would work, but its not quite right as in this case its
>>>>> about format, but might be about some other twiddle ( say endianess)
>>>>> for other specifications.  If would be nice if the convention applied
>>>>> to more than ECDSA and DSA.  I'm not opposed to the proposal though.
>>>>>
>>>>> My counter proposal would be for <algorithm>[/<specification>] as the
>>>>> naming convention.  With the general contract that all implementations
>>>>> of <algorithm> share the same general math at least for KeyAgreement
>>>>> and Signature but may not share the same concrete representations or
>>>>> encodings (e.g. there's difference in the encoding of the shared
>>>>> secret output from DH for TLS vs pretty much everything else - has to
>>>>> do with the integer to octet string conversion).  Again, not opposed
>>>>> to the naming convention you suggested, just trying to think in meta
>>>>> terms.
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> The intent is to reduce potential confusion with the extended
>>>>>> algorithm Strings specifying MGF functions
>>>>>> (<digest>with<encryption>and<mgf>) by using the word "in" for
>>>>>> conjunction and to append "Format" to the format name.
>>>>>>
>>>>>> Would you be ok with this solution?
>>>>>>
>>>>>> Thanks,
>>>>>> Jason
>>>>>>
>>>>>> On 1/29/15 7:27 AM, Sean Mullan wrote:
>>>>>>> On 01/27/2015 05:40 PM, Michael StJohns wrote:
>>>>>>>> So what I'm concerned with is surprise.  I'm also concerned with
>>>>>>>> "default signature formats" from new providers.  Right now, I
>>>>>>>> know if
>>>>>>>> I ask for ECDSA, the output of Signature will be in a very specific
>>>>>>>> format, and the math will match what's in FIPS 186-4, X9.62 and
>>>>>>>> SECG.
>>>>>>>> I'm really uncomfortable about changing that.  I think the
>>>>>>>> algorithm
>>>>>>>> name should map to one specific suite of math and input/output
>>>>>>>> formats.
>>>>>>>
>>>>>>> Yes, your argument makes sense, and we will change the fix to use
>>>>>>> new
>>>>>>> algorithm Strings that specify the P1363 format. Jason will be
>>>>>>> following
>>>>>>> up with more details on that.
>>>>>>>
>>>>>>> Thanks for weighing in on this issue and spending the time to
>>>>>>> explain
>>>>>>> your concerns.
>>>>>>>
>>>>>>> --Sean
>>>>>
>>>>>
>>>>

From vladimir.kozlov at oracle.com  Tue Feb 17 18:41:51 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 17 Feb 2015 10:41:51 -0800
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E38909.5070800@oracle.com>
References: <54E25D03.7090705@oracle.com> <54E2982D.9020902@oracle.com>
	<54E2A10A.6090007@oracle.com> <54E38909.5070800@oracle.com>
Message-ID: <54E38B6F.9050106@oracle.com>

On 2/17/15 10:31 AM, Anthony Scarpino wrote:
> On 02/16/2015 06:01 PM, Vladimir Kozlov wrote:
>> On 2/16/15 5:23 PM, David Holmes wrote:
>>> Hi Tony,
>>>
>>> Not a review as hotspot compiler folk need to review this.
>>>
>>> On 17/02/2015 7:11 AM, Anthony Scarpino wrote:
>>>> Hi,
>>>>
>>>> I'm requesting a code review to intrinsify the GHASH operations for
>>>> both
>>>> x86 and SPARC platforms.  This greatly increases performance over
>>>> software for AES/GCM crypto operations, details are in the bug.
>>>
>>> This may be normal for intrinsics but there seems to be a large amount
>>> of shared code being updated to support these platform specific
>>> enhancements. What happens on other platforms if the user sets
>>> UseGHASHIntrinsics? Shouldn't there be a guard against this in
>>> arguments.cpp?
>>
>> Code in vm_version_<arch>.cpp does the check. vm_version_sparc.cpp and
>> vm_version_x86.cpp do that.
>>
>> Tony, please, fix other vm_version_<arch>.cpp files (including closed)
>> to set corresponding flag to false. See UseAES as example.
>
> Ok.. thanks Dave & Vladimir for bring that up.. I fix that..
>
>
>> Also code in vm_version_sparc.cpp should be similar to one in
>> vm_version_x86.cpp. Something like:
>>
>>    // GHASH/GCM intrinsics
>>    if (has_vis3() && (UseVIS > 2)) {
>>      if (FLAG_IS_DEFAULT(UseGHASHIntrinsics)) {
>>        UseGHASHIntrinsics = true;
>>      }
>>    } else if (UseGHASHIntrinsics) {
>>      if (!FLAG_IS_DEFAULT(UseGHASHIntrinsics))
>>        warning("GHASH intrinsics require VIS3 insructions support.
>> Intriniscs will be disabled");
>>      FLAG_SET_DEFAULT(UseGHASHIntrinsics, false);
>>    }
>>
>
> Sure..
>
>> There is #ifdef _WIN64 in stubGenerator_x86_32.cpp. It is not needed
>> since it is 32-bit code.
>
> Sure.. Do I still need to save the xmm6 and xmm7 on 32bit code, or is
> all of the register saving only for Windows 64bit?

No, in 32-bit you don't need to save xmm6 and xmm7.

>
>>
>> I see you switched off -DcheckOutput=false for GCM testing and return
>> from compareArrays() after length compare. Is it because it can't be
>> done or you did not have time to add needed code?
>
> I'll have to double check, but I believe -DcheckOutput can be turned
> back on.  I suspect I never updated the @run lines after I changed
> compareArrays()

In void compareArrays(byte b[], byte exp[]) {

You have:

+    if (mode.equals("GCM"))
+      return;
      for (int i=0; i< exp.length; i++) {
        if (b[i] != exp[i]) {

So current changes do not compare arrays elements for GCM. That is why I 
asked.

Thanks,
Vladimir

>
>> Otherwise Hotspot code looks good.
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> Thanks,
>>> David
>>>
>>>> The review is for two repos, hotspot and jdk:
>>>>
>>>> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/
>>>>
>>>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/
>>>>
>>>> thanks
>>>>
>>>> Tony
>

From anthony.scarpino at oracle.com  Tue Feb 17 18:49:12 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Tue, 17 Feb 2015 10:49:12 -0800
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <31E530B4-B880-4630-A830-663145817AC1@oracle.com>
References: <54E25D03.7090705@oracle.com>
	<31E530B4-B880-4630-A830-663145817AC1@oracle.com>
Message-ID: <54E38D28.2070305@oracle.com>

On 02/16/2015 06:47 PM, John Rose wrote:
> Cool stuff.  I'm glad to see SPARC xmulx getting some play.
>
> This is not a review, but I have a small and a big comment.
>
> You don't need the argument vmIntrinsics::ID id unless you are going
> to do something with it, such as expand one of a family of intrinsics
> covered by the same LCK::inline* routine.

Sure.. In my following the AES intrinsics as an example, I didn't catch 
'id' pointlessness..

> You probably don't have enough parameter verification on the inputs
> to processBlocks.  A robust range check for a subsequence indexing
> operation requires three comparison operations, not just one.  The
> Java code uses getLong which includes additional range checks, but
> your intrinsic replacement code might not do that correctly; in any
> case, it's better to have all the subsequence range checks in one
> place, and in Java code.  (Oh, and watch out for 32-bit integer
> overflow:  That causes surprises sometimes, when a value that is too
> large wraps to negative, and then can seem to be in range relative to
> a <= check.)
>
> In fact, I don't believe the existing parameter verification is very
> helpful at all:
>
> if (inLen - inOfs > in.length)  throw...
>
> This appears to allow a ridiculously large inLen as long as inOfs is
> also ridiculously large.  All of the "heavy lifting" is done by
> intrinisic array range checks triggered by getLong, and those are the
> checks that the assembly code does *not* do.

Ok.. thanks.. I'll double check the range checking code..

>
> ? John
>
> P.S.  We should have a library API to do these parameter checks.
> See:
> https://bugs.openjdk.java.net/browse/JDK-8042997#comment-13610181
>
> On Feb 16, 2015, at 1:11 PM, Anthony Scarpino
> <anthony.scarpino at oracle.com> wrote:
>>
>> Hi,
>>
>> I'm requesting a code review to intrinsify the GHASH operations for
>> both x86 and SPARC platforms.  This greatly increases performance
>> over software for AES/GCM crypto operations, details are in the
>> bug.
>>
>> The review is for two repos, hotspot and jdk:
>>
>> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/
>>
>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/
>>
>> thanks
>>
>> Tony
>


From sean.mullan at oracle.com  Tue Feb 17 19:42:11 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 17 Feb 2015 14:42:11 -0500
Subject: RFR 8073182: keytool may generate duplicate extensions
In-Reply-To: <54E1A2AF.3010203@oracle.com>
References: <54E1A2AF.3010203@oracle.com>
Message-ID: <54E39993.5000207@oracle.com>

You should probably update the keytool doc to say that if duplicate 
extensions are specified, only the last one is added.

Also, unrelated to you fix but can you break up that really long line 
(1213) in KeyToolTest?

Looks fine otherwise.

--Sean

On 02/16/2015 02:56 AM, 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 duplicate.
>
> Existing test updated.
>
> Thanks
> Max

From anthony.scarpino at oracle.com  Tue Feb 17 19:46:31 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Tue, 17 Feb 2015 11:46:31 -0800
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E38B6F.9050106@oracle.com>
References: <54E25D03.7090705@oracle.com> <54E2982D.9020902@oracle.com>
	<54E2A10A.6090007@oracle.com> <54E38909.5070800@oracle.com>
	<54E38B6F.9050106@oracle.com>
Message-ID: <54E39A97.3060206@oracle.com>

On 02/17/2015 10:41 AM, Vladimir Kozlov wrote:
> On 2/17/15 10:31 AM, Anthony Scarpino wrote:
>> On 02/16/2015 06:01 PM, Vladimir Kozlov wrote:
>>> There is #ifdef _WIN64 in stubGenerator_x86_32.cpp. It is not needed
>>> since it is 32-bit code.
>>
>> Sure.. Do I still need to save the xmm6 and xmm7 on 32bit code, or is
>> all of the register saving only for Windows 64bit?
>
> No, in 32-bit you don't need to save xmm6 and xmm7.

Ok, thanks

>
>>
>>>
>>> I see you switched off -DcheckOutput=false for GCM testing and return
>>> from compareArrays() after length compare. Is it because it can't be
>>> done or you did not have time to add needed code?
>>
>> I'll have to double check, but I believe -DcheckOutput can be turned
>> back on.  I suspect I never updated the @run lines after I changed
>> compareArrays()
>
> In void compareArrays(byte b[], byte exp[]) {
>
> You have:
>
> +    if (mode.equals("GCM"))
> +      return;
>       for (int i=0; i< exp.length; i++) {
>         if (b[i] != exp[i]) {
>
> So current changes do not compare arrays elements for GCM. That is why I
> asked.

I did this because there are checks in GCM to prevent reusing IVs.  The 
current design of the hotspot test reuses IVs so that the encrypted or 
decrypted result is returned o compare, which is ok for CBC and ECB. 
Since I wasn't able to get a reproducible result for GCM, I skipped the 
array checking.  What I am depending on to test GCM is the TestGHASH 
test in the jdk repo, which is a Known Answer Test, to make sure the 
GHASH intrinsics are correct to the spec.

All that being said, I will look at this again.  I originally didn't 
want to completely redesign the hotspot tests when I had TestGHASH 
already, but I'll go back to see what changes I can do to hopefully get 
compareArrays working.

Tony

From anthony.scarpino at oracle.com  Tue Feb 17 19:59:08 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Tue, 17 Feb 2015 11:59:08 -0800
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E3028A.7040102@redhat.com>
References: <54E25D03.7090705@oracle.com> <54E3028A.7040102@redhat.com>
Message-ID: <54E39D8C.8050705@oracle.com>

On 02/17/2015 12:57 AM, Florian Weimer wrote:
> On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/
>
> I think the ?state? field in GHASH should be final.  Is C2 able to
> eliminate the array bounds checks?  (Although it's not in the inner loop
> and thus probably not relevant for performance.)

I'm not sure want you asking about in regard to the bounds checking? 
Are you asking about checking the bounds of "state"?

>
> The comment on processBlock(byte[], int, int) is confusing.  I don't
> understand what it is trying to say.

That is why I can never proofread my own writing. :)
I'll fix that up.. What means to say is the method arguments list and 
method name cannot be changed, along with some operations inside the 
method cannot occur or it can break intrinsics.

From anthony.scarpino at oracle.com  Tue Feb 17 20:03:52 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Tue, 17 Feb 2015 12:03:52 -0800
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E31F05.2020805@redhat.com>
References: <54E25D03.7090705@oracle.com> <54E31F05.2020805@redhat.com>
Message-ID: <54E39EA8.6080004@oracle.com>

On 02/17/2015 02:59 AM, Florian Weimer wrote:
> On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
>> Hi,
>>
>> I'm requesting a code review to intrinsify the GHASH operations for both
>> x86 and SPARC platforms.  This greatly increases performance over
>> software for AES/GCM crypto operations, details are in the bug.
>>
>> The review is for two repos, hotspot and jdk:
>>
>> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/
>
> Sorry for double-posting.
>
> I looked at generate_ghash_processBlocks() and wonder if the loop needs
> to be split to introduce occasional safepoints.  The TLS record size
> should limit the number bytes per invocation to 16000, so perhaps this
> isn't issue for the current application.

I would think TLS limits should be handled in a JSSE or other TLS area. 
  I think GHASH should be the pure implementation.

Tony



From fweimer at redhat.com  Tue Feb 17 20:05:14 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 17 Feb 2015 21:05:14 +0100
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E39D8C.8050705@oracle.com>
References: <54E25D03.7090705@oracle.com> <54E3028A.7040102@redhat.com>
	<54E39D8C.8050705@oracle.com>
Message-ID: <54E39EFA.8060904@redhat.com>

On 02/17/2015 08:59 PM, Anthony Scarpino wrote:
> On 02/17/2015 12:57 AM, Florian Weimer wrote:
>> On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
>>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/
>>
>> I think the ?state? field in GHASH should be final.  Is C2 able to
>> eliminate the array bounds checks?  (Although it's not in the inner loop
>> and thus probably not relevant for performance.)
> 
> I'm not sure want you asking about in regard to the bounds checking? Are
> you asking about checking the bounds of "state"?

state[0] and state[1]?I wonder if those expressions need array bounds
checks when compiled.

>> The comment on processBlock(byte[], int, int) is confusing.  I don't
>> understand what it is trying to say.
> 
> That is why I can never proofread my own writing. :)
> I'll fix that up.. What means to say is the method arguments list and
> method name cannot be changed, along with some operations inside the
> method cannot occur or it can break intrinsics.

Yes, that's certainly helpful.  Usually, the JDK does not have hints
pointing to Hotspot intrinsics.  But most of them deal with public APIs
which are frozen anyway.

-- 
Florian Weimer / Red Hat Product Security

From fweimer at redhat.com  Tue Feb 17 20:06:19 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 17 Feb 2015 21:06:19 +0100
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E39EA8.6080004@oracle.com>
References: <54E25D03.7090705@oracle.com> <54E31F05.2020805@redhat.com>
	<54E39EA8.6080004@oracle.com>
Message-ID: <54E39F3B.2030006@redhat.com>

On 02/17/2015 09:03 PM, Anthony Scarpino wrote:
> On 02/17/2015 02:59 AM, Florian Weimer wrote:
>> On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
>>> Hi,
>>>
>>> I'm requesting a code review to intrinsify the GHASH operations for both
>>> x86 and SPARC platforms.  This greatly increases performance over
>>> software for AES/GCM crypto operations, details are in the bug.
>>>
>>> The review is for two repos, hotspot and jdk:
>>>
>>> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/
>>
>> Sorry for double-posting.
>>
>> I looked at generate_ghash_processBlocks() and wonder if the loop needs
>> to be split to introduce occasional safepoints.  The TLS record size
>> should limit the number bytes per invocation to 16000, so perhaps this
>> isn't issue for the current application.
> 
> I would think TLS limits should be handled in a JSSE or other TLS area.
>  I think GHASH should be the pure implementation.

Sorry, what I'm trying to say is that TLS won't trigger this issue
because its loops will be reasonably short.

There might be other users for which this could be a problem, though.

-- 
Florian Weimer / Red Hat Product Security

From jason.uh at oracle.com  Tue Feb 17 20:59:05 2015
From: jason.uh at oracle.com (Jason Uh)
Date: Tue, 17 Feb 2015 12:59:05 -0800
Subject: [9] Review Request: 8072663: Remove the sun.security.acl package
	which is not used in the JDK
Message-ID: <54E3AB99.1050107@oracle.com>

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 for 
java.security.acl only covers the three exception classes and there are 
no JDK tests for the interfaces, implying that the spec does not require 
the implementation of java.security.acl interfaces. This is likely 
because java.security.acl package have been superseded by classes in the 
java.security package since 1.2.

Removing the sun.security.acl implementation will help offset the 
increase in size to the base module that was caused by moving 
java.security.acl from a separate dedicated module to java.base (see 
http://bugs.openjdk.java.net/browse/JDK-8069551).

Thanks,
Jason

From anthony.scarpino at oracle.com  Tue Feb 17 21:00:41 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Tue, 17 Feb 2015 13:00:41 -0800
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E39EFA.8060904@redhat.com>
References: <54E25D03.7090705@oracle.com> <54E3028A.7040102@redhat.com>
	<54E39D8C.8050705@oracle.com> <54E39EFA.8060904@redhat.com>
Message-ID: <54E3ABF9.3030706@oracle.com>

On 02/17/2015 12:05 PM, Florian Weimer wrote:
> On 02/17/2015 08:59 PM, Anthony Scarpino wrote:
>> On 02/17/2015 12:57 AM, Florian Weimer wrote:
>>> On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
>>>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/
>>>
>>> I think the ?state? field in GHASH should be final.  Is C2 able to
>>> eliminate the array bounds checks?  (Although it's not in the inner loop
>>> and thus probably not relevant for performance.)
>>
>> I'm not sure want you asking about in regard to the bounds checking? Are
>> you asking about checking the bounds of "state"?
>
> state[0] and state[1]?I wonder if those expressions need array bounds
> checks when compiled.

The glossary says C2 eliminates array range checking.
http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html

Tony


From vladimir.kozlov at oracle.com  Tue Feb 17 21:14:49 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 17 Feb 2015 13:14:49 -0800
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E3ABF9.3030706@oracle.com>
References: <54E25D03.7090705@oracle.com>
	<54E3028A.7040102@redhat.com>	<54E39D8C.8050705@oracle.com>
	<54E39EFA.8060904@redhat.com> <54E3ABF9.3030706@oracle.com>
Message-ID: <54E3AF49.6060102@oracle.com>

Florian's concern is valid.

"Range check elimination" means that C2 moves checks from a loop. Checks 
are still present. Since 'state' array is not final we can't eliminate 
range check. An other thing is an additional indirect load to access 
arrays elements.

I would suggest to keep original code for 'subkey' and 'state' which use 
separate values instead of arrays.

Regards,
Vladimir


On 2/17/15 1:00 PM, Anthony Scarpino wrote:
> On 02/17/2015 12:05 PM, Florian Weimer wrote:
>> On 02/17/2015 08:59 PM, Anthony Scarpino wrote:
>>> On 02/17/2015 12:57 AM, Florian Weimer wrote:
>>>> On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
>>>>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/
>>>>
>>>> I think the ?state? field in GHASH should be final.  Is C2 able to
>>>> eliminate the array bounds checks?  (Although it's not in the inner
>>>> loop
>>>> and thus probably not relevant for performance.)
>>>
>>> I'm not sure want you asking about in regard to the bounds checking? Are
>>> you asking about checking the bounds of "state"?
>>
>> state[0] and state[1]?I wonder if those expressions need array bounds
>> checks when compiled.
>
> The glossary says C2 eliminates array range checking.
> http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html
>
> Tony
>

From sean.mullan at oracle.com  Tue Feb 17 21:21:55 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 17 Feb 2015 16:21:55 -0500
Subject: [9] Review Request: 8072663: Remove the sun.security.acl package
	which is not used in the JDK
In-Reply-To: <54E3AB99.1050107@oracle.com>
References: <54E3AB99.1050107@oracle.com>
Message-ID: <54E3B0F3.8030200@oracle.com>

Looks fine to me (pending CCC approval).

--Sean

On 02/17/2015 03:59 PM, Jason Uh wrote:
> 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 for
> java.security.acl only covers the three exception classes and there are
> no JDK tests for the interfaces, implying that the spec does not require
> the implementation of java.security.acl interfaces. This is likely
> because java.security.acl package have been superseded by classes in the
> java.security package since 1.2.
>
> Removing the sun.security.acl implementation will help offset the
> increase in size to the base module that was caused by moving
> java.security.acl from a separate dedicated module to java.base (see
> http://bugs.openjdk.java.net/browse/JDK-8069551).
>
> Thanks,
> Jason

From anthony.scarpino at oracle.com  Tue Feb 17 22:03:33 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Tue, 17 Feb 2015 14:03:33 -0800
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E3AF49.6060102@oracle.com>
References: <54E25D03.7090705@oracle.com>
	<54E3028A.7040102@redhat.com>	<54E39D8C.8050705@oracle.com>
	<54E39EFA.8060904@redhat.com> <54E3ABF9.3030706@oracle.com>
	<54E3AF49.6060102@oracle.com>
Message-ID: <54E3BAB5.8090506@oracle.com>

On 02/17/2015 01:14 PM, Vladimir Kozlov wrote:
> Florian's concern is valid.
>
> "Range check elimination" means that C2 moves checks from a loop. Checks
> are still present. Since 'state' array is not final we can't eliminate
> range check.

I don't understand the concern here.  The arrays are private and are 
only used by math calculations either in the same GHASH object or by the 
intrinsics.  What ranges check issues are we expecting to occur given 
they are inaccessible by an API?

> An other thing is an additional indirect load to access
> arrays elements.
>
> I would suggest to keep original code for 'subkey' and 'state' which use
> separate values instead of arrays.

By the indirect loading, you referring to the loading done by 
get_vars_from_ghash_object() in library_call.cpp?  If so, I thought it 
would be faster to load the 128bit values directly into one register 
instead of loading one long from the class to a register, shift left, 
loading the second long and xor'ing into the register.  The assembly 
code is doing the math on the whole 128bit value, while the GHASH.java 
side needs to split it into 2 values.  Putting it into an array makes in 
easy, coding wise, to access the whole 128bit value at once.

If the suggestion also is to put the 4 longs on the argument list, that 
would be 7 arguments for processBlocks, which would be ugly and not 
useful for the non-intrinsic side since GHASH.java would ignore the longs.

 >
> Regards,
> Vladimir
>
>
> On 2/17/15 1:00 PM, Anthony Scarpino wrote:
>> On 02/17/2015 12:05 PM, Florian Weimer wrote:
>>> On 02/17/2015 08:59 PM, Anthony Scarpino wrote:
>>>> On 02/17/2015 12:57 AM, Florian Weimer wrote:
>>>>> On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
>>>>>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/
>>>>>
>>>>> I think the ?state? field in GHASH should be final.  Is C2 able to
>>>>> eliminate the array bounds checks?  (Although it's not in the inner
>>>>> loop
>>>>> and thus probably not relevant for performance.)
>>>>
>>>> I'm not sure want you asking about in regard to the bounds checking?
>>>> Are
>>>> you asking about checking the bounds of "state"?
>>>
>>> state[0] and state[1]?I wonder if those expressions need array bounds
>>> checks when compiled.
>>
>> The glossary says C2 eliminates array range checking.
>> http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html
>>
>> Tony
>>


From vladimir.kozlov at oracle.com  Tue Feb 17 22:30:08 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 17 Feb 2015 14:30:08 -0800
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E3BAB5.8090506@oracle.com>
References: <54E25D03.7090705@oracle.com>
	<54E3028A.7040102@redhat.com>	<54E39D8C.8050705@oracle.com>
	<54E39EFA.8060904@redhat.com> <54E3ABF9.3030706@oracle.com>
	<54E3AF49.6060102@oracle.com> <54E3BAB5.8090506@oracle.com>
Message-ID: <54E3C0F0.5090203@oracle.com>

The concern was about java code and not intrinsic. If intrinsic is not 
used we will get additional range checks which were not present before.

By indirect load I mean object->array_oop->element instead of object->field.

But in blockMult() you access them outside main loops. As result the 
code without intrinsic should not be affected much.

So, please, ignore my suggestion about "keep 'subkey' and 'state' 
original values". You are right for intrinsic it is better to use arrays.

Anyway, all is fine except you may need to check that size of arrays is 
at least 2 before calling processBlocks().

thanks,
Vladimir

On 2/17/15 2:03 PM, Anthony Scarpino wrote:
> On 02/17/2015 01:14 PM, Vladimir Kozlov wrote:
>> Florian's concern is valid.
>>
>> "Range check elimination" means that C2 moves checks from a loop. Checks
>> are still present. Since 'state' array is not final we can't eliminate
>> range check.
>
> I don't understand the concern here.  The arrays are private and are
> only used by math calculations either in the same GHASH object or by the
> intrinsics.  What ranges check issues are we expecting to occur given
> they are inaccessible by an API?
>
>> An other thing is an additional indirect load to access
>> arrays elements.
>>
>> I would suggest to keep original code for 'subkey' and 'state' which use
>> separate values instead of arrays.
>
> By the indirect loading, you referring to the loading done by
> get_vars_from_ghash_object() in library_call.cpp?  If so, I thought it
> would be faster to load the 128bit values directly into one register
> instead of loading one long from the class to a register, shift left,
> loading the second long and xor'ing into the register.  The assembly
> code is doing the math on the whole 128bit value, while the GHASH.java
> side needs to split it into 2 values.  Putting it into an array makes in
> easy, coding wise, to access the whole 128bit value at once.
>
> If the suggestion also is to put the 4 longs on the argument list, that
> would be 7 arguments for processBlocks, which would be ugly and not
> useful for the non-intrinsic side since GHASH.java would ignore the longs.
>
>  >
>> Regards,
>> Vladimir
>>
>>
>> On 2/17/15 1:00 PM, Anthony Scarpino wrote:
>>> On 02/17/2015 12:05 PM, Florian Weimer wrote:
>>>> On 02/17/2015 08:59 PM, Anthony Scarpino wrote:
>>>>> On 02/17/2015 12:57 AM, Florian Weimer wrote:
>>>>>> On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
>>>>>>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/
>>>>>>
>>>>>> I think the ?state? field in GHASH should be final.  Is C2 able to
>>>>>> eliminate the array bounds checks?  (Although it's not in the inner
>>>>>> loop
>>>>>> and thus probably not relevant for performance.)
>>>>>
>>>>> I'm not sure want you asking about in regard to the bounds checking?
>>>>> Are
>>>>> you asking about checking the bounds of "state"?
>>>>
>>>> state[0] and state[1]?I wonder if those expressions need array bounds
>>>> checks when compiled.
>>>
>>> The glossary says C2 eliminates array range checking.
>>> http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html
>>>
>>> Tony
>>>
>

From fweimer at redhat.com  Tue Feb 17 23:52:11 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Wed, 18 Feb 2015 00:52:11 +0100
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E3C0F0.5090203@oracle.com>
References: <54E25D03.7090705@oracle.com>
	<54E3028A.7040102@redhat.com>	<54E39D8C.8050705@oracle.com>
	<54E39EFA.8060904@redhat.com> <54E3ABF9.3030706@oracle.com>
	<54E3AF49.6060102@oracle.com> <54E3BAB5.8090506@oracle.com>
	<54E3C0F0.5090203@oracle.com>
Message-ID: <54E3D42B.2010202@redhat.com>

On 02/17/2015 11:30 PM, Vladimir Kozlov wrote:
> The concern was about java code and not intrinsic. If intrinsic is not
> used we will get additional range checks which were not present before.
> 
> By indirect load I mean object->array_oop->element instead of
> object->field.
> 
> But in blockMult() you access them outside main loops. As result the
> code without intrinsic should not be affected much.

Making the state field final is still a good idea, I think.

-- 
Florian Weimer / Red Hat Product Security

From anthony.scarpino at oracle.com  Tue Feb 17 23:57:15 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Tue, 17 Feb 2015 15:57:15 -0800
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E3C0F0.5090203@oracle.com>
References: <54E25D03.7090705@oracle.com>
	<54E3028A.7040102@redhat.com>	<54E39D8C.8050705@oracle.com>
	<54E39EFA.8060904@redhat.com> <54E3ABF9.3030706@oracle.com>
	<54E3AF49.6060102@oracle.com> <54E3BAB5.8090506@oracle.com>
	<54E3C0F0.5090203@oracle.com>
Message-ID: <54E3D55B.60507@oracle.com>

Ok, I'll add these checks.. Thanks for looking through this.

Tony

On 02/17/2015 02:30 PM, Vladimir Kozlov wrote:
> The concern was about java code and not intrinsic. If intrinsic is not
> used we will get additional range checks which were not present before.
>
> By indirect load I mean object->array_oop->element instead of
> object->field.
>
> But in blockMult() you access them outside main loops. As result the
> code without intrinsic should not be affected much.
>
> So, please, ignore my suggestion about "keep 'subkey' and 'state'
> original values". You are right for intrinsic it is better to use arrays.
>
> Anyway, all is fine except you may need to check that size of arrays is
> at least 2 before calling processBlocks().
>
> thanks,
> Vladimir
>
> On 2/17/15 2:03 PM, Anthony Scarpino wrote:
>> On 02/17/2015 01:14 PM, Vladimir Kozlov wrote:
>>> Florian's concern is valid.
>>>
>>> "Range check elimination" means that C2 moves checks from a loop. Checks
>>> are still present. Since 'state' array is not final we can't eliminate
>>> range check.
>>
>> I don't understand the concern here.  The arrays are private and are
>> only used by math calculations either in the same GHASH object or by the
>> intrinsics.  What ranges check issues are we expecting to occur given
>> they are inaccessible by an API?
>>
>>> An other thing is an additional indirect load to access
>>> arrays elements.
>>>
>>> I would suggest to keep original code for 'subkey' and 'state' which use
>>> separate values instead of arrays.
>>
>> By the indirect loading, you referring to the loading done by
>> get_vars_from_ghash_object() in library_call.cpp?  If so, I thought it
>> would be faster to load the 128bit values directly into one register
>> instead of loading one long from the class to a register, shift left,
>> loading the second long and xor'ing into the register.  The assembly
>> code is doing the math on the whole 128bit value, while the GHASH.java
>> side needs to split it into 2 values.  Putting it into an array makes in
>> easy, coding wise, to access the whole 128bit value at once.
>>
>> If the suggestion also is to put the 4 longs on the argument list, that
>> would be 7 arguments for processBlocks, which would be ugly and not
>> useful for the non-intrinsic side since GHASH.java would ignore the
>> longs.
>>
>>  >
>>> Regards,
>>> Vladimir
>>>
>>>
>>> On 2/17/15 1:00 PM, Anthony Scarpino wrote:
>>>> On 02/17/2015 12:05 PM, Florian Weimer wrote:
>>>>> On 02/17/2015 08:59 PM, Anthony Scarpino wrote:
>>>>>> On 02/17/2015 12:57 AM, Florian Weimer wrote:
>>>>>>> On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
>>>>>>>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/
>>>>>>>
>>>>>>> I think the ?state? field in GHASH should be final.  Is C2 able to
>>>>>>> eliminate the array bounds checks?  (Although it's not in the inner
>>>>>>> loop
>>>>>>> and thus probably not relevant for performance.)
>>>>>>
>>>>>> I'm not sure want you asking about in regard to the bounds checking?
>>>>>> Are
>>>>>> you asking about checking the bounds of "state"?
>>>>>
>>>>> state[0] and state[1]?I wonder if those expressions need array bounds
>>>>> checks when compiled.
>>>>
>>>> The glossary says C2 eliminates array range checking.
>>>> http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html
>>>>
>>>> Tony
>>>>
>>


From anthony.scarpino at oracle.com  Tue Feb 17 23:59:47 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Tue, 17 Feb 2015 15:59:47 -0800
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E3D42B.2010202@redhat.com>
References: <54E25D03.7090705@oracle.com>
	<54E3028A.7040102@redhat.com>	<54E39D8C.8050705@oracle.com>
	<54E39EFA.8060904@redhat.com> <54E3ABF9.3030706@oracle.com>
	<54E3AF49.6060102@oracle.com> <54E3BAB5.8090506@oracle.com>
	<54E3C0F0.5090203@oracle.com> <54E3D42B.2010202@redhat.com>
Message-ID: <54E3D5F3.60201@oracle.com>

On 02/17/2015 03:52 PM, Florian Weimer wrote:
> On 02/17/2015 11:30 PM, Vladimir Kozlov wrote:
>> The concern was about java code and not intrinsic. If intrinsic is not
>> used we will get additional range checks which were not present before.
>>
>> By indirect load I mean object->array_oop->element instead of
>> object->field.
>>
>> But in blockMult() you access them outside main loops. As result the
>> code without intrinsic should not be affected much.
>
> Making the state field final is still a good idea, I think.
>

Sure.. I think it's reasonable to add that too..  thanks

Tony


From oss at qualeed.com  Wed Feb 18 00:06:31 2015
From: oss at qualeed.com (Dai Nakanishi)
Date: Wed, 18 Feb 2015 09:06:31 +0900
Subject: [PATCH] CipherStream produces new byte array on every update or
	doFinal operation
Message-ID: <20150218090630.95DF.B5B9BC9E@qualeed.com>

Hi,

CipherInputStream and CipherOutputStream call the Cipher methods update
and doFinal which produce new byte array. It may consume a large amount
of memory.

The purpose of my patch is to avoid this. Could you review the patch?

Thanks,
Dai

--- old/src/share/classes/javax/crypto/CipherInputStream.java	Thu Feb 12 11:55:05 2015 +0900
+++ new/src/share/classes/javax/crypto/CipherInputStream.java	Tue Feb 17 17:12:08 2015 +0900
@@ -108,34 +108,50 @@
         read = true;
         if (readin == -1) {
             done = true;
+            ensureCapacity(0);
             try {
-                obuffer = cipher.doFinal();
-            } catch (IllegalBlockSizeException | BadPaddingException e) {
+                ofinish = cipher.doFinal(obuffer, 0);
+            } catch (IllegalBlockSizeException | BadPaddingException
+                    | ShortBufferException e) {
                 obuffer = null;
                 throw new IOException(e);
             }
-            if (obuffer == null)
+            if (ofinish == 0)
                 return -1;
             else {
                 ostart = 0;
-                ofinish = obuffer.length;
                 return ofinish;
             }
         }
+        ensureCapacity(readin);
         try {
-            obuffer = cipher.update(ibuffer, 0, readin);
+            ofinish = cipher.update(ibuffer, 0, readin, obuffer);
         } catch (IllegalStateException e) {
             obuffer = null;
             throw e;
+        } catch (ShortBufferException e) {
+            obuffer = null;
+            throw new IOException(e);
         }
         ostart = 0;
-        if (obuffer == null)
-            ofinish = 0;
-        else ofinish = obuffer.length;
         return ofinish;
     }
 
     /**
+     * Ensure the capacity of the output buffer for the next
+     * update or doFinal operation, given the input length
+     * <code>inputLen</code> (in bytes)
+     * 
+     * @param inputLen the input length (in bytes)
+     */
+    private void ensureCapacity(int inputLen) {
+        int outputLen = cipher.getOutputSize(inputLen);
+        if (obuffer == null || obuffer.length < outputLen) {
+            obuffer = new byte[outputLen];
+        }
+    }
+    
+    /**
      * Constructs a CipherInputStream from an InputStream and a
      * Cipher.
      * <br>Note: if the specified input stream or cipher is
@@ -311,10 +327,12 @@
         try {
             // throw away the unprocessed data
             if (!done) {
-                cipher.doFinal();
+                ensureCapacity(0);
+                cipher.doFinal(obuffer, 0);
             }
         }
-        catch (BadPaddingException | IllegalBlockSizeException ex) {
+        catch (BadPaddingException | IllegalBlockSizeException
+                | ShortBufferException ex) {
             /* If no data has been read from the stream to be en/decrypted,
                we supress any exceptions, and close quietly. */
             if (read) {


--- old/src/share/classes/javax/crypto/CipherOutputStream.java	Thu Feb 12 11:55:05 2015 +0900
+++ new/src/share/classes/javax/crypto/CipherOutputStream.java	Tue Feb 17 18:48:01 2015 +0900
@@ -74,6 +74,9 @@
     // the buffer holding data ready to be written out
     private byte[] obuffer;
 
+    // the number of bytes stored in the output buffer 
+    private int ostored = 0;
+
     // stream status
     private boolean closed = false;
 
@@ -118,10 +121,15 @@
      */
     public void write(int b) throws IOException {
         ibuffer[0] = (byte) b;
-        obuffer = cipher.update(ibuffer, 0, 1);
-        if (obuffer != null) {
-            output.write(obuffer);
-            obuffer = null;
+        ensureCapacity(1);
+        try {
+            ostored = cipher.update(ibuffer, 0, 1, obuffer);
+        } catch (ShortBufferException e) {
+            throw new IOException(e);
+        }
+        if (ostored > 0) {
+            output.write(obuffer, 0, ostored);
+            ostored = 0;
         }
     };
 
@@ -155,10 +163,15 @@
      * @since      JCE1.2
      */
     public void write(byte b[], int off, int len) throws IOException {
-        obuffer = cipher.update(b, off, len);
-        if (obuffer != null) {
-            output.write(obuffer);
-            obuffer = null;
+        ensureCapacity(len);
+        try {
+            ostored = cipher.update(b, off, len, obuffer);
+        } catch (ShortBufferException e) {
+            throw new IOException(e);
+        }
+        if (ostored > 0) {
+            output.write(obuffer, 0, ostored);
+            ostored = 0;
         }
     }
 
@@ -177,9 +190,9 @@
      * @since      JCE1.2
      */
     public void flush() throws IOException {
-        if (obuffer != null) {
-            output.write(obuffer);
-            obuffer = null;
+        if (obuffer != null && ostored > 0) {
+            output.write(obuffer, 0, ostored);
+            ostored = 0;
         }
         output.flush();
     }
@@ -206,14 +219,31 @@
         }
 
         closed = true;
+        ensureCapacity(0);
         try {
-            obuffer = cipher.doFinal();
-        } catch (IllegalBlockSizeException | BadPaddingException e) {
+            ostored = cipher.doFinal(obuffer, 0);
+        } catch (IllegalBlockSizeException | BadPaddingException
+                | ShortBufferException e) {
             obuffer = null;
+            ostored = 0;
         }
         try {
             flush();
         } catch (IOException ignored) {}
         out.close();
+    }
+
+    /**
+     * Ensure the capacity of the output buffer for the next
+     * update or doFinal operation, given the input length
+     * <code>inputLen</code> (in bytes)
+     * 
+     * @param inputLen the input length (in bytes)
+     */
+    private void ensureCapacity(int inputLen) {
+        int outputLen = cipher.getOutputSize(inputLen);
+        if (obuffer == null || obuffer.length < outputLen) {
+            obuffer = new byte[outputLen];
+        }
     }
 }


From Alan.Bateman at oracle.com  Wed Feb 18 07:03:06 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 18 Feb 2015 07:03:06 +0000
Subject: [9] Review Request: 8072663: Remove the sun.security.acl package
	which is not used in the JDK
In-Reply-To: <54E3AB99.1050107@oracle.com>
References: <54E3AB99.1050107@oracle.com>
Message-ID: <54E4392A.4080307@oracle.com>

On 17/02/2015 20:59, Jason Uh wrote:
> 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 for 
> java.security.acl only covers the three exception classes and there 
> are no JDK tests for the interfaces, implying that the spec does not 
> require the implementation of java.security.acl interfaces. This is 
> likely because java.security.acl package have been superseded by 
> classes in the java.security package since 1.2.
>
> Removing the sun.security.acl implementation will help offset the 
> increase in size to the base module that was caused by moving 
> java.security.acl from a separate dedicated module to java.base (see 
> http://bugs.openjdk.java.net/browse/JDK-8069551).
The changes looks good, assuming there is no way that the 
sun.security.acl classes will be used by anything else in the standard 
APi. I didn't realize there was a reference to the implementation 
classes in the java.security.acl javadoc.

-Alan

From mandy.chung at oracle.com  Wed Feb 18 18:48:00 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 18 Feb 2015 10:48:00 -0800
Subject: [9] Review Request: 8072663: Remove the sun.security.acl package
	which is not used in the JDK
In-Reply-To: <54E3AB99.1050107@oracle.com>
References: <54E3AB99.1050107@oracle.com>
Message-ID: <54E4DE60.9050409@oracle.com>

On 2/17/15 12:59 PM, Jason Uh wrote:
> 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

Looks fine.  While the java.security.acl package is small, it'd be nice 
if this package will be gone in a future release.

Mandy

From anthony.scarpino at oracle.com  Fri Feb 20 00:52:47 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 19 Feb 2015 16:52:47 -0800
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E25D03.7090705@oracle.com>
References: <54E25D03.7090705@oracle.com>
Message-ID: <54E6855F.4050308@oracle.com>

I've updated the webrevs.  I believe I've added everyone's comments.
- Changed GHASHIntrinsics and disabled for non-supported platforms
- removing WIN64 ifdef in 32bit x86
- fixed hotspot test so it can use compareArray()
- modified the range checking
- fixed processBlocks comment

http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.01/

http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.01/

thanks

Tony


From vladimir.kozlov at oracle.com  Fri Feb 20 01:36:58 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 19 Feb 2015 17:36:58 -0800
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E6855F.4050308@oracle.com>
References: <54E25D03.7090705@oracle.com> <54E6855F.4050308@oracle.com>
Message-ID: <54E68FBA.1090904@oracle.com>

JDK changes review.
-------------------
All exceptions should print invalid value as you did for state and 
subkeyH checks. It would greatly help debugging.

Please, split first check into 3 separate checks and print invalid value 
to know which condition failed.

Missing space after 'length': "invalid length"+subkeyH.length


Hotspot review.
---------------
Everything seems fine. Thank you for fixing the test.

What do you mean "Changed GHASHIntrinsics"? Don't pass intrinsic_id or 
something else?

Thanks,
Vladimir

On 2/19/15 4:52 PM, Anthony Scarpino wrote:
> I've updated the webrevs.  I believe I've added everyone's comments.
> - Changed GHASHIntrinsics and disabled for non-supported platforms
> - removing WIN64 ifdef in 32bit x86
> - fixed hotspot test so it can use compareArray()
> - modified the range checking
> - fixed processBlocks comment
>
> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.01/
>
> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.01/
>
> thanks
>
> Tony
>

From anthony.scarpino at oracle.com  Fri Feb 20 05:22:50 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 19 Feb 2015 21:22:50 -0800
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E68FBA.1090904@oracle.com>
References: <54E25D03.7090705@oracle.com> <54E6855F.4050308@oracle.com>
	<54E68FBA.1090904@oracle.com>
Message-ID: <E3EE29AF-1C49-4CC3-9B10-B5FE9649AD8C@oracle.com>


On Feb 19, 2015, at 5:36 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> JDK changes review.
> -------------------
> All exceptions should print invalid value as you did for state and subkeyH checks. It would greatly help debugging.
> 
> Please, split first check into 3 separate checks and print invalid value to know which condition failed.
> 
> Missing space after 'length': "invalid length?+subkeyH.length

Ok.. I?ll make those changes 

> 
> Hotspot review.
> ---------------
> Everything seems fine. Thank you for fixing the test.
> 
> What do you mean "Changed GHASHIntrinsics"? Don't pass intrinsic_id or something else?

I combined the two change into one bullet point.  Your comment about merging has_vis3() and UseVIS into one if() in vm_version_sparc.cpp and the addition code to prevent other platforms from using the flag.  Both involved GHASHIntrinsics.

Tony

> Thanks,
> Vladimir
> 
> On 2/19/15 4:52 PM, Anthony Scarpino wrote:
>> I've updated the webrevs.  I believe I've added everyone's comments.
>> - Changed GHASHIntrinsics and disabled for non-supported platforms
>> - removing WIN64 ifdef in 32bit x86
>> - fixed hotspot test so it can use compareArray()
>> - modified the range checking
>> - fixed processBlocks comment
>> 
>> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.01/
>> 
>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.01/
>> 
>> thanks
>> 
>> Tony
>> 


From weijun.wang at oracle.com  Fri Feb 20 12:21:13 2015
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 20 Feb 2015 20:21:13 +0800
Subject: RFR 8073182: keytool may generate duplicate extensions
In-Reply-To: <54E39993.5000207@oracle.com>
References: <54E1A2AF.3010203@oracle.com> <54E39993.5000207@oracle.com>
Message-ID: <54E726B9.7050600@oracle.com>

Yes, that line has 354 chars. There are quite a lot of long lines there, 
maybe because keytool command is usually long. In fact, 43 lines are 
longer than 150 chars, 345 lines longer than 80 chars. Shall I fix all 
of them?

Thanks
Max

On 2/18/2015 3:42, Sean Mullan wrote:
> Also, unrelated to you fix but can you break up that really long line
> (1213) in KeyToolTest?

From sean.mullan at oracle.com  Fri Feb 20 12:46:30 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 20 Feb 2015 07:46:30 -0500
Subject: RFR 8073182: keytool may generate duplicate extensions
In-Reply-To: <54E726B9.7050600@oracle.com>
References: <54E1A2AF.3010203@oracle.com> <54E39993.5000207@oracle.com>
	<54E726B9.7050600@oracle.com>
Message-ID: <54E72CA6.9060401@oracle.com>

On 02/20/2015 07:21 AM, Weijun Wang wrote:
> Yes, that line has 354 chars. There are quite a lot of long lines there,
> maybe because keytool command is usually long. In fact, 43 lines are
> longer than 150 chars, 345 lines longer than 80 chars. Shall I fix all
> of them?

If it's not too much work, sure.

--Sean

>
> Thanks
> Max
>
> On 2/18/2015 3:42, Sean Mullan wrote:
>> Also, unrelated to you fix but can you break up that really long line
>> (1213) in KeyToolTest?

From weijun.wang at oracle.com  Fri Feb 20 13:24:57 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Fri, 20 Feb 2015 21:24:57 +0800
Subject: RFR 8073182: keytool may generate duplicate extensions
In-Reply-To: <54E72CA6.9060401@oracle.com>
References: <54E1A2AF.3010203@oracle.com> <54E39993.5000207@oracle.com>
	<54E726B9.7050600@oracle.com> <54E72CA6.9060401@oracle.com>
Message-ID: <6D0EB89F-AAB2-49C5-9881-B8804C1C681A@oracle.com>


> On Feb 20, 2015, at 20:46, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 02/20/2015 07:21 AM, Weijun Wang wrote:
>> Yes, that line has 354 chars. There are quite a lot of long lines there,
>> maybe because keytool command is usually long. In fact, 43 lines are
>> longer than 150 chars, 345 lines longer than 80 chars. Shall I fix all
>> of them?
> 
> If it's not too much work, sure.

OK.

Can you also look at 8073181 fix?

Thanks
Max

> 
> --Sean
> 
>> 
>> Thanks
>> Max
>> 
>> On 2/18/2015 3:42, Sean Mullan wrote:
>>> Also, unrelated to you fix but can you break up that really long line
>>> (1213) in KeyToolTest?


From valerie.peng at oracle.com  Fri Feb 20 19:50:08 2015
From: valerie.peng at oracle.com (Valerie Peng)
Date: Fri, 20 Feb 2015 11:50:08 -0800
Subject: [PATCH] CipherStream produces new byte array on every update
	or doFinal operation
In-Reply-To: <20150218090630.95DF.B5B9BC9E@qualeed.com>
References: <20150218090630.95DF.B5B9BC9E@qualeed.com>
Message-ID: <54E78FF0.9050805@oracle.com>


I started with this, but I have a pressing higher priority tasks at hand.
So, it will take me a few weeks to wrap this up.
Regards,
Valerie

On 2/17/2015 4:06 PM, Dai Nakanishi wrote:
> Hi,
>
> CipherInputStream and CipherOutputStream call the Cipher methods update
> and doFinal which produce new byte array. It may consume a large amount
> of memory.
>
> The purpose of my patch is to avoid this. Could you review the patch?
>
> Thanks,
> Dai
>
> --- old/src/share/classes/javax/crypto/CipherInputStream.java	Thu Feb 12 11:55:05 2015 +0900
> +++ new/src/share/classes/javax/crypto/CipherInputStream.java	Tue Feb 17 17:12:08 2015 +0900
> @@ -108,34 +108,50 @@
>           read = true;
>           if (readin == -1) {
>               done = true;
> +            ensureCapacity(0);
>               try {
> -                obuffer = cipher.doFinal();
> -            } catch (IllegalBlockSizeException | BadPaddingException e) {
> +                ofinish = cipher.doFinal(obuffer, 0);
> +            } catch (IllegalBlockSizeException | BadPaddingException
> +                    | ShortBufferException e) {
>                   obuffer = null;
>                   throw new IOException(e);
>               }
> -            if (obuffer == null)
> +            if (ofinish == 0)
>                   return -1;
>               else {
>                   ostart = 0;
> -                ofinish = obuffer.length;
>                   return ofinish;
>               }
>           }
> +        ensureCapacity(readin);
>           try {
> -            obuffer = cipher.update(ibuffer, 0, readin);
> +            ofinish = cipher.update(ibuffer, 0, readin, obuffer);
>           } catch (IllegalStateException e) {
>               obuffer = null;
>               throw e;
> +        } catch (ShortBufferException e) {
> +            obuffer = null;
> +            throw new IOException(e);
>           }
>           ostart = 0;
> -        if (obuffer == null)
> -            ofinish = 0;
> -        else ofinish = obuffer.length;
>           return ofinish;
>       }
>
>       /**
> +     * Ensure the capacity of the output buffer for the next
> +     * update or doFinal operation, given the input length
> +     *<code>inputLen</code>  (in bytes)
> +     *
> +     * @param inputLen the input length (in bytes)
> +     */
> +    private void ensureCapacity(int inputLen) {
> +        int outputLen = cipher.getOutputSize(inputLen);
> +        if (obuffer == null || obuffer.length<  outputLen) {
> +            obuffer = new byte[outputLen];
> +        }
> +    }
> +
> +    /**
>        * Constructs a CipherInputStream from an InputStream and a
>        * Cipher.
>        *<br>Note: if the specified input stream or cipher is
> @@ -311,10 +327,12 @@
>           try {
>               // throw away the unprocessed data
>               if (!done) {
> -                cipher.doFinal();
> +                ensureCapacity(0);
> +                cipher.doFinal(obuffer, 0);
>               }
>           }
> -        catch (BadPaddingException | IllegalBlockSizeException ex) {
> +        catch (BadPaddingException | IllegalBlockSizeException
> +                | ShortBufferException ex) {
>               /* If no data has been read from the stream to be en/decrypted,
>                  we supress any exceptions, and close quietly. */
>               if (read) {
>
>
> --- old/src/share/classes/javax/crypto/CipherOutputStream.java	Thu Feb 12 11:55:05 2015 +0900
> +++ new/src/share/classes/javax/crypto/CipherOutputStream.java	Tue Feb 17 18:48:01 2015 +0900
> @@ -74,6 +74,9 @@
>       // the buffer holding data ready to be written out
>       private byte[] obuffer;
>
> +    // the number of bytes stored in the output buffer
> +    private int ostored = 0;
> +
>       // stream status
>       private boolean closed = false;
>
> @@ -118,10 +121,15 @@
>        */
>       public void write(int b) throws IOException {
>           ibuffer[0] = (byte) b;
> -        obuffer = cipher.update(ibuffer, 0, 1);
> -        if (obuffer != null) {
> -            output.write(obuffer);
> -            obuffer = null;
> +        ensureCapacity(1);
> +        try {
> +            ostored = cipher.update(ibuffer, 0, 1, obuffer);
> +        } catch (ShortBufferException e) {
> +            throw new IOException(e);
> +        }
> +        if (ostored>  0) {
> +            output.write(obuffer, 0, ostored);
> +            ostored = 0;
>           }
>       };
>
> @@ -155,10 +163,15 @@
>        * @since      JCE1.2
>        */
>       public void write(byte b[], int off, int len) throws IOException {
> -        obuffer = cipher.update(b, off, len);
> -        if (obuffer != null) {
> -            output.write(obuffer);
> -            obuffer = null;
> +        ensureCapacity(len);
> +        try {
> +            ostored = cipher.update(b, off, len, obuffer);
> +        } catch (ShortBufferException e) {
> +            throw new IOException(e);
> +        }
> +        if (ostored>  0) {
> +            output.write(obuffer, 0, ostored);
> +            ostored = 0;
>           }
>       }
>
> @@ -177,9 +190,9 @@
>        * @since      JCE1.2
>        */
>       public void flush() throws IOException {
> -        if (obuffer != null) {
> -            output.write(obuffer);
> -            obuffer = null;
> +        if (obuffer != null&&  ostored>  0) {
> +            output.write(obuffer, 0, ostored);
> +            ostored = 0;
>           }
>           output.flush();
>       }
> @@ -206,14 +219,31 @@
>           }
>
>           closed = true;
> +        ensureCapacity(0);
>           try {
> -            obuffer = cipher.doFinal();
> -        } catch (IllegalBlockSizeException | BadPaddingException e) {
> +            ostored = cipher.doFinal(obuffer, 0);
> +        } catch (IllegalBlockSizeException | BadPaddingException
> +                | ShortBufferException e) {
>               obuffer = null;
> +            ostored = 0;
>           }
>           try {
>               flush();
>           } catch (IOException ignored) {}
>           out.close();
> +    }
> +
> +    /**
> +     * Ensure the capacity of the output buffer for the next
> +     * update or doFinal operation, given the input length
> +     *<code>inputLen</code>  (in bytes)
> +     *
> +     * @param inputLen the input length (in bytes)
> +     */
> +    private void ensureCapacity(int inputLen) {
> +        int outputLen = cipher.getOutputSize(inputLen);
> +        if (obuffer == null || obuffer.length<  outputLen) {
> +            obuffer = new byte[outputLen];
> +        }
>       }
>   }
>

From anthony.scarpino at oracle.com  Fri Feb 20 20:58:31 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Fri, 20 Feb 2015 12:58:31 -0800
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E68FBA.1090904@oracle.com>
References: <54E25D03.7090705@oracle.com> <54E6855F.4050308@oracle.com>
	<54E68FBA.1090904@oracle.com>
Message-ID: <54E79FF7.1040800@oracle.com>

On 02/19/2015 05:36 PM, Vladimir Kozlov wrote:
> JDK changes review.
> -------------------
> All exceptions should print invalid value as you did for state and
> subkeyH checks. It would greatly help debugging.
>
> Please, split first check into 3 separate checks and print invalid value
> to know which condition failed.
>
> Missing space after 'length': "invalid length"+subkeyH.length

webrev updated:
http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.02/

Tony


From sean.mullan at oracle.com  Fri Feb 20 22:23:13 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 20 Feb 2015 17:23:13 -0500
Subject: RFR 8072394: java.security.cert.PolicyQualifierInfo needs
	value-based equality
In-Reply-To: <54E35086.7090408@redhat.com>
References: <54D0A628.3080404@redhat.com> <54DE53E9.7010200@oracle.com>
	<54DE5B96.9000704@redhat.com> <54E26B6C.3040202@oracle.com>
	<54E35086.7090408@redhat.com>
Message-ID: <54E7B3D1.4070402@oracle.com>

On 02/17/2015 09:30 AM, Florian Weimer wrote:
> On 02/16/2015 11:13 PM, Sean Mullan wrote:
>
>>> Based on that, PolicyQualifierInfo should have implemented value-based
>>> equals() and hashCode(), and the identity-based set is just a bug.  (But
>>> the requirement I cited is a stronger requirement the Set would not
>>> enforce.)
>>>
>>> However, I think it's too late to fix this bug now.  That's why I just
>>> added the identity counter.  If you want the behavioral change instead,
>>> I can implement that as well.
>>
>> Maybe it's not too late. This is not a commonly used class, and the
>> compatibility risk is probably fairly low. If you code up the changes, I
>> can file a CCC on your behalf.
>
> Updated webrev: <http://cr.openjdk.java.net/~fweimer/8072394/webrev.01/>

You need to add a description for the overridden equals/hashCode 
methods, ex:

/**
  * Compares the specified object with this PolicyQualifierInfo for
  * equality.
  *
  * Returns true, if and only if the specified object is also a
  * PolicyQualifierInfo and the encoded bytes are the same.
  *
  * @return true, if the specified object is equal to this
  *    PolicyQualifierInfo, false otherwise
  */
@Override
public boolean equals(Object o) {

/**
  * Returns the hashcode for this PolicyQualifierInfo. The hash code
  * is the result of Arrays.hashcode on the encoded bytes of the
  * PolicyQualifierInfo.
  *
  * @return the hashcode for this PolicyQualifierInfo
  */
@Override
public int hashCode() {

--Sean

>
> I sneaked in a memory model fix to make the class really immutable, and
> simplified the constructor a bit (mEncoded is already a copy, there is
> no need for further copying).
>
> There's also a new tested, mostly copied from the existing
> GetPolicyQualifiers test.  (I didn't want to edit the existing test be
> cause that sometimes causes trouble.)  The DER values were generated by
> pyasn1 and verified using Peter Gutmann's dumpasn1.
>
> I couldn't find any other tests for PolicyQualifierInfo, but you may
> have closed tests that need adjusting.
>

From vladimir.kozlov at oracle.com  Sat Feb 21 01:42:47 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 20 Feb 2015 17:42:47 -0800
Subject: RFR: 8073108: GHASH Intrinsics
In-Reply-To: <54E79FF7.1040800@oracle.com>
References: <54E25D03.7090705@oracle.com> <54E6855F.4050308@oracle.com>
	<54E68FBA.1090904@oracle.com> <54E79FF7.1040800@oracle.com>
Message-ID: <54E7E297.4010501@oracle.com>

Perfect. No more comments from me.

Thanks,
Vladimir

On 2/20/15 12:58 PM, Anthony Scarpino wrote:
> On 02/19/2015 05:36 PM, Vladimir Kozlov wrote:
>> JDK changes review.
>> -------------------
>> All exceptions should print invalid value as you did for state and
>> subkeyH checks. It would greatly help debugging.
>>
>> Please, split first check into 3 separate checks and print invalid value
>> to know which condition failed.
>>
>> Missing space after 'length': "invalid length"+subkeyH.length
>
> webrev updated:
> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.02/
>
> Tony
>

From sean.mullan at oracle.com  Tue Feb 24 15:44:47 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 24 Feb 2015 10:44:47 -0500
Subject: RFR 8073181: keytool -ext honored not working correctly
In-Reply-To: <54E153FE.4020807@oracle.com>
References: <54E153FE.4020807@oracle.com>
Message-ID: <54EC9C6F.6050504@oracle.com>

Looks fine to me.

--Sean

On 02/15/2015 09:20 PM, Weijun Wang wrote:
> Hi All
>
> Please review the fix at
>
>      http://cr.openjdk.java.net/~weijun/8073181/webrev.00/
>
> The old honored code have 2 problems:
>
> 1. type not read if bare name without critical suffix
> 2. extension not added if critical flag is not modified
>
> Thanks
> Max

From sean.coffey at oracle.com  Tue Feb 24 20:27:26 2015
From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=)
Date: Tue, 24 Feb 2015 20:27:26 +0000
Subject: [9] RFR: 8054037: Improve tracing for java.security.debug=certpath
In-Reply-To: <54DD3FD4.3000106@oracle.com>
References: <54DD3FD4.3000106@oracle.com>
Message-ID: <54ECDEAE.8020202@oracle.com>

Hi Jason,

I just spotted this thread now. Thanks for taking this on. I'd like to 
do some testing with your new patch and get back to you tomorrow. Will 
update then!

regards,
Sean.

On 13/02/2015 00:05, Jason Uh wrote:
> 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


From weijun.wang at oracle.com  Wed Feb 25 15:41:42 2015
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 25 Feb 2015 23:41:42 +0800
Subject: RFR 8073853: KeyToolTest.java has too many too long lines
Message-ID: <54EDED36.5030300@oracle.com>

Hi Sean

Please review the change at

   http://cr.openjdk.java.net/~weijun/8073853/webrev.00

After the change, the output of the following command does not change at 
all.

   javac -g:vars,source KeyToolTest.java

Thanks
Max

From amanda.jiang at oracle.com  Wed Feb 25 20:41:40 2015
From: amanda.jiang at oracle.com (Amanda Jiang)
Date: Wed, 25 Feb 2015 14:41:40 -0600
Subject: Please review CR8048360 Test signed jar files
Message-ID: <54EE3384.1080104@oracle.com>

Hi All,

Could you please review following changeset for 1 new test, which check 
various combinations of permissions to execute the code from a signed 
jar file.

Bug: https://bugs.openjdk.java.net/browse/JDK-8048360
webrev: http://cr.openjdk.java.net/~tyan/amandaj/8048360/webrev.01/ 
<http://cr.openjdk.java.net/%7Etyan/amandaj/8048360/webrev.01/>

Thanks,
Amanda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20150225/641cf023/attachment.html>

From amanda.jiang at oracle.com  Wed Feb 25 20:54:57 2015
From: amanda.jiang at oracle.com (Amanda Jiang)
Date: Wed, 25 Feb 2015 14:54:57 -0600
Subject: Please review CR 8050409: Test for JAAS getPrivateCredentials
Message-ID: <54EE36A1.5020802@oracle.com>

Hi All,

Could you please review following changeset, which includes one new test 
to test permission checks with Subject.getPrivateCredentials.

Bug: https://bugs.openjdk.java.net/browse/JDK-8050409
Webrev:http://cr.openjdk.java.net/~tyan/amandaj/8050409/webrev.02/

Thanks,
Amanda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20150225/73fad552/attachment.html>

From sean.mullan at oracle.com  Wed Feb 25 23:56:27 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 25 Feb 2015 18:56:27 -0500
Subject: RFR 8073853: KeyToolTest.java has too many too long lines
In-Reply-To: <54EDED36.5030300@oracle.com>
References: <54EDED36.5030300@oracle.com>
Message-ID: <54EE612B.80201@oracle.com>

Looks fine.

--Sean

On 02/25/2015 10:41 AM, Weijun Wang wrote:
> Hi Sean
>
> Please review the change at
>
>    http://cr.openjdk.java.net/~weijun/8073853/webrev.00
>
> After the change, the output of the following command does not change at
> all.
>
>    javac -g:vars,source KeyToolTest.java
>
> Thanks
> Max

From weijun.wang at oracle.com  Thu Feb 26 00:24:26 2015
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 26 Feb 2015 08:24:26 +0800
Subject: Please review CR8048360 Test signed jar files
In-Reply-To: <54EE3384.1080104@oracle.com>
References: <54EE3384.1080104@oracle.com>
Message-ID: <54EE67BA.1080105@oracle.com>

Looks fine.

Thanks
Max

On 2/26/2015 4:41, Amanda Jiang wrote:
> Hi All,
>
> Could you please review following changeset for 1 new test, which check
> various combinations of permissions to execute the code from a signed
> jar file.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8048360
> webrev: http://cr.openjdk.java.net/~tyan/amandaj/8048360/webrev.01/
> <http://cr.openjdk.java.net/%7Etyan/amandaj/8048360/webrev.01/>
>
> Thanks,
> Amanda

From vincent.x.ryan at oracle.com  Thu Feb 26 13:24:59 2015
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Thu, 26 Feb 2015 13:24:59 +0000
Subject: [9] code review request for 8073955: Update java.security.debug help
	text to reflect recent enhancements for debugging
Message-ID: <59C33D54-1927-4DBE-A417-E380E3B55047@oracle.com>

Please review this minor change update the help text provided for the java.security.debug system property.
Additional debugging flags have been added recently and the help text needs updating.

Thanks.

Bug:  https://bugs.openjdk.java.net/browse/JDK-8073955
Webrev:  http://cr.openjdk.java.net/~vinnie/8073955/webrev.00/


From sean.mullan at oracle.com  Thu Feb 26 15:15:05 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 26 Feb 2015 10:15:05 -0500
Subject: [9] code review request for 8073955: Update java.security.debug
	help text to reflect recent enhancements for debugging
In-Reply-To: <59C33D54-1927-4DBE-A417-E380E3B55047@oracle.com>
References: <59C33D54-1927-4DBE-A417-E380E3B55047@oracle.com>
Message-ID: <54EF3879.7070203@oracle.com>

Looks fine. Can you also open a corresponding docs bug to update the 
Troubleshooting Guide [1] with these new options? Please file it in the 
docs/guides component and add a "securitydocs" label. Also, there are a 
few existing options (pkcs11, etc) which are not documented in that 
guide - could you add those to the docs bug too?

Thanks,
Sean

[1] 
http://docs.oracle.com/javase/8/docs/technotes/guides/security/troubleshooting-security.html


On 02/26/2015 08:24 AM, Vincent Ryan wrote:
> Please review this minor change update the help text provided for the java.security.debug system property.
> Additional debugging flags have been added recently and the help text needs updating.
>
> Thanks.
>
> Bug:  https://bugs.openjdk.java.net/browse/JDK-8073955
> Webrev:  http://cr.openjdk.java.net/~vinnie/8073955/webrev.00/
>

From vincent.x.ryan at oracle.com  Thu Feb 26 16:26:34 2015
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Thu, 26 Feb 2015 16:26:34 +0000
Subject: [9] code review request for 8073955: Update java.security.debug
	help text to reflect recent enhancements for debugging
In-Reply-To: <54EF3879.7070203@oracle.com>
References: <59C33D54-1927-4DBE-A417-E380E3B55047@oracle.com>
	<54EF3879.7070203@oracle.com>
Message-ID: <3649ADA1-FADD-4A08-A2CD-7A197D9830FF@oracle.com>

Done.
  https://bugs.openjdk.java.net/browse/JDK-8073976

Thanks Sean.


On 26 Feb 2015, at 15:15, Sean Mullan <sean.mullan at oracle.com> wrote:

> Looks fine. Can you also open a corresponding docs bug to update the Troubleshooting Guide [1] with these new options? Please file it in the docs/guides component and add a "securitydocs" label. Also, there are a few existing options (pkcs11, etc) which are not documented in that guide - could you add those to the docs bug too?
> 
> Thanks,
> Sean
> 
> [1] http://docs.oracle.com/javase/8/docs/technotes/guides/security/troubleshooting-security.html
> 
> 
> On 02/26/2015 08:24 AM, Vincent Ryan wrote:
>> Please review this minor change update the help text provided for the java.security.debug system property.
>> Additional debugging flags have been added recently and the help text needs updating.
>> 
>> Thanks.
>> 
>> Bug:  https://bugs.openjdk.java.net/browse/JDK-8073955
>> Webrev:  http://cr.openjdk.java.net/~vinnie/8073955/webrev.00/
>> 


From florian.bruckner at 3kraft.com  Fri Feb 27 06:52:23 2015
From: florian.bruckner at 3kraft.com (Florian Bruckner (3kraft))
Date: Fri, 27 Feb 2015 07:52:23 +0100
Subject: apple.security.KeychainStore does not load private key (when
	called from javaws)
In-Reply-To: <5450D025.30602@oracle.com>
References: <53C40783.4060204@3kraft.com>	<53C4ECC8.3020909@3kraft.com>	<53D75D03.4070403@3kraft.com>	<0F9AD930-8C72-4BC9-A0FA-A5A5CDA850FC@oracle.com>	<53DFA249.3000207@3kraft.com>	<53E134E6.5070707@oracle.com>
	<53F5B33B.2040007@3kraft.com>	<D7590593-064B-4DDD-88F3-8E5C4537F44C@oracle.com>	<543D1615.2020509@3kraft.com>	<11D9CF89-1135-42D0-B75B-68653588495D@oracle.com>	<544F5BA9.9090507@3kraft.com>	<50418EAD-5635-437E-B410-ECD7F52717FB@oracle.com>	<544F7A0C.6010200@3kraft.com>
	<E8FB8985-1B92-49AC-9284-6C005D13643E@oracle.com>
	<5450D025.30602@oracle.com>
Message-ID: <54F01427.9060408@3kraft.com>

Hi Vincent,

now that this change has been in 9 for some time - so you see a chance to have this also accepted 
for JDK8?

regards,

Florian

On 29/10/14 12:31, Sean Mullan wrote:
> Looks fine to me.
>
> --Sean
>
> On 10/28/2014 02:42 PM, Vincent Ryan wrote:
>> OK thanks. I had been looking for your name in that list.
>>
>> In addition, changesets require a testcase to verify the fix so I've
>> modified an existing keychain testcase.
>> I?ve updated the previous webrev, in place:
>>
>> http://cr.openjdk.java.net/~vinnie/8062264/webrev.00/
>>
>>
>>
>> On 28 Oct 2014, at 11:12, Florian Bruckner (3kraft)
>> <florian.bruckner at 3kraft.com <mailto:florian.bruckner at 3kraft.com>> wrote:
>>
>>> Hi Vincent,
>>>
>>> the webrev looks good.
>>>
>>> I have also received confirmation that the OCA was approved - looking
>>> at the address you mentioned, it is listed with the company name
>>> "3kraft IT GmbH & Co KG".
>>>
>>> regards,
>>>
>>> Florian
>>>
>>> On 28.10.14 11:50, Vincent Ryan wrote:
>>>> No problem. I made a slight modification to your fix to replace the
>>>> fixed password with a randomly generated one.
>>>> Here?s the webrev:
>>>> http://cr.openjdk.java.net/~vinnie/8062264/webrev.00/
>>>> <http://cr.openjdk.java.net/%7Evinnie/8062264/webrev.00/>
>>>>
>>>> If you?re OK with that then I?ll push your fix along with two other
>>>> fixes to KeychainStore.
>>>>
>>>>
>>>> BTW OCA approval is required before your patch can be integrated and
>>>> I don?t see your name listed at:
>>>> http://www.oracle.com/technetwork/community/oca-486395.html
>>>>
>>>> Did you receive a confirmation email?
>>>>
>>>
>>
>


From weijun.wang at oracle.com  Fri Feb 27 09:15:13 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Fri, 27 Feb 2015 17:15:13 +0800
Subject: RFR 8074018: Named extension not recognized in keytool -ext honored
	after 8073182
Message-ID: <B6ED1E94-AC00-473E-B989-91214105456F@oracle.com>

Hi Sean

Please review the fix at

  http://cr.openjdk.java.net/~weijun/8074018/webrev.00/

This is a regression of my code change for 8073182.

Thanks
Max


From sean.mullan at oracle.com  Fri Feb 27 20:12:01 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 27 Feb 2015 15:12:01 -0500
Subject: RFR 8074018: Named extension not recognized in keytool -ext
	honored after 8073182
In-Reply-To: <B6ED1E94-AC00-473E-B989-91214105456F@oracle.com>
References: <B6ED1E94-AC00-473E-B989-91214105456F@oracle.com>
Message-ID: <54F0CF91.9000203@oracle.com>

Looks fine.

--Sean

On 02/27/2015 04:15 AM, Wang Weijun wrote:
> Hi Sean
>
> Please review the fix at
>
>    http://cr.openjdk.java.net/~weijun/8074018/webrev.00/
>
> This is a regression of my code change for 8073182.
>
> Thanks
> Max
>