Re: RFR: 8168911: Increased number of classes initialized during initialization of SignatureFileVerifier

[Anthony Scarpino]

On 11/04/2016 08:09 AM, Claes Redestad wrote:

Hi,

changes to SignatureFileVerifier in 9+142 has some startup implications,
and a small
cleanup to avoid some trivial regexes etc reduces number of classes
initialized in affected
startup tests by 61, undoing most of the observed regression.

Webrev: http://cr.openjdk.java.net/~redestad/8168911/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8168911

Thanks!

/Claes


The change looks fine.. thanks

Tony

Re: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar

[Wang Weijun]

Everything looks fine now.

--Max

> On Nov 8, 2016, at 11:09 AM, Artem Smotrakov  
> wrote:
> 
> Here is final version (I hope)
> 
> http://cr.openjdk.java.net/~asmotrak/8168882/webrev.04/
> 
> Artem

Re: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar

[Artem Smotrakov]

Sean, Max,

Please take a look at 
http://cr.openjdk.java.net/~asmotrak/8168882/webrev.03/


It doesn't print a warning anymore, and reset the security property only 
if -jarfile specified. I also updated a couple of tests to check if 
"-printcert" works fine.


Artem


On 11/03/2016 05:47 PM, Artem Smotrakov wrote:

Thank you for review Sean.

I'll remove the warning then. And I'll update it to reset the security 
property only if a jar file has been specified.


Let me also check how "-printcert -file ..." and "-printcert 
-sslserver" work.


Artem


On 11/03/2016 07:27 AM, Wang Weijun wrote:

I agree with Sean.

--Max

On Nov 3, 2016, at 10:00 PM, Sean Mullan  
wrote:


You should only unset the jdk.jar.disabledAlgorithms property if a 
jarfile has been specified.


Also, you are printing the warning message for all usages of the 
-printcert option, -ssl, etc, which is not correct.


But I don't really think the warning message is necessary. The docs 
for the -printcert option are pretty clear that it simply extracts 
the certificate and prints it. If we are going to put a warning in 
for signed JARs, then arguably we should put in a more general, 
simple warning in for all usages of this option to say that the 
certificate, etc is not verified, ex:


"WARNING: The -printcert option does not verify the certificate."

But again, I don't think this is strictly necessary.

Thanks,
Sean

Re: Updates to documentation for JEP 287

[Sean Mullan]

There's a bug open to update the Standard Names doc to include SHA-3: 
https://bugs.openjdk.java.net/browse/JDK-8004078


The security guides typically get updated a bit later. I don't have an 
estimate but it will be done before 9 is released.


Thanks,
Sean


On 10/29/16 11:08 AM, Jurrian Fahner wrote:

Hi all,

I discovered that for Java 9, the following page is not updated for the
new hashing algorithms:
http://download.java.net/java/jdk9/docs/technotes/guides/security/StandardNames.html

I don't know whether it is on your to do list, if it is already an item
then just ignore this email.
If I can be of any assistance, please let me know.

Kind regards,

Jurrian Fahner

Re: RFR: 8157561 :Ship the unlimited policy files in JDK Updates

[Bradford Wetmore]

Great, thanks.  Looks good.

Brad



On 11/7/2016 3:34 AM, Seán Coffey wrote:

Thanks for review Brad. I've included an extra check in CryptoLevel to
check for "limited/unlimited" input. Addressed the JceSecurity
indentation issue also.

http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v5/webrev/

Regards,
Sean.

On 04/11/16 22:56, Bradford Wetmore wrote:

I didn't see anything majorly different in what I looked at earlier, I
didn't check java.security or the test case.


CryptoLevel.java

49: Your usage mentions only unlimited|limited.  Do you want to
include a check for that?

JceSecurity.java

300:  Indention problem.

Looks ok otherwise.

Thanks,

Brad




On 11/4/2016 7:16 AM, Erik Joelsson wrote:

Build changes look ok to me.

/Erik


On 2016-11-04 14:42, Seán Coffey wrote:

Looking to push this enhancement to jdk8u. The change introduces the
new Security property which was brought into JDK 9 via JDK-8061842.

The code differs in that jar files continue to be used and backwards
compatibility is maintained. If the new security property is not
defined and the policy jar files exist in the legacy locations, then
those jar files will continue to be honoured.

https://bugs.openjdk.java.net/browse/JDK-8157561
webrev :
http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v4/webrev/

Re: Code Review Request, JDK-8169318, Dump the reproduced packet in DTLSOverDatagram.java

[Sean Mullan]

Looks fine to me.

--Sean

On 11/7/16 7:00 AM, Xuelei Fan wrote:

Hi,

Please review this test update:

   http://cr.openjdk.java.net/~xuelei/8169318/webrev.00/

This update is related to JDK-8169086.  From the debug log of
JDK-8169086, it is hard to tell the failure is cause by anti-free-port
issue or not.  So I filed a new bug JDK-8169318, and want to expose more
information for further evaluation.

In the fix, retransmitted packet data will be dumped on timeout.

Thanks,
Xuelei

Code Review Request, JDK-8169318, Dump the reproduced packet in DTLSOverDatagram.java

[Xuelei Fan]

Hi,

Please review this test update:

   http://cr.openjdk.java.net/~xuelei/8169318/webrev.00/

This update is related to JDK-8169086.  From the debug log of 
JDK-8169086, it is hard to tell the failure is cause by anti-free-port 
issue or not.  So I filed a new bug JDK-8169318, and want to expose more 
information for further evaluation.


In the fix, retransmitted packet data will be dumped on timeout.

Thanks,
Xuelei

Re: RFR: 8157561 :Ship the unlimited policy files in JDK Updates

[Seán Coffey]

Thanks for review Brad. I've included an extra check in CryptoLevel to 
check for "limited/unlimited" input. Addressed the JceSecurity 
indentation issue also.


http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v5/webrev/

Regards,
Sean.

On 04/11/16 22:56, Bradford Wetmore wrote:
I didn't see anything majorly different in what I looked at earlier, I 
didn't check java.security or the test case.



CryptoLevel.java

49: Your usage mentions only unlimited|limited.  Do you want to 
include a check for that?


JceSecurity.java

300:  Indention problem.

Looks ok otherwise.

Thanks,

Brad




On 11/4/2016 7:16 AM, Erik Joelsson wrote:

Build changes look ok to me.

/Erik


On 2016-11-04 14:42, Seán Coffey wrote:

Looking to push this enhancement to jdk8u. The change introduces the
new Security property which was brought into JDK 9 via JDK-8061842.

The code differs in that jar files continue to be used and backwards
compatibility is maintained. If the new security property is not
defined and the policy jar files exist in the legacy locations, then
those jar files will continue to be honoured.

https://bugs.openjdk.java.net/browse/JDK-8157561
webrev :
http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v4/webrev/

Re: RFR 7004967: SecureRandom should be more explicit about threading

[Wang Weijun]

Accepted.

Please review http://ccc.us.oracle.com/8169312. In fact, can we 
deprecate the getSeed() method? It's not unsafe so we don't need to give 
it a forRemoval value.


Thanks
Max

On 11/4/2016 10:54 PM, Sean Mullan wrote:

* SecureRandom

 131  * If this attribute is not set or is "false", this class will instead
 132  * synchronize access to each of the methods of the {@code
SecureRandomSpi}
 133  * implementation.

Not all of the methods are synchronized - engineGetParameters is not,
for example. I think to avoid ambiguity, you should list the names of
the methods that are synchronized.

810  * @throws IllegalArgumentException if {@code numBytes} is negative

Since this is a new @throws, you really need to file a new CCC (or
withdraw and amend the current one with this @throws).

Please also file a docs bug with a description of the new attribute.

* SecureRandomSpi

lines 63-83, I think the wording could be improved/simplified, how about:

See {@link SecureRandom} for additional details on thread safety. By
default, a SecureRandomSpi implementation is considered to be not safe
for use by multiple concurrent threads and SecureRandom will synchronize
access to each of the applicable engine methods (see SecureRandom for
the list of methods). However, if a SecureRandomSpi implementation is
thread-safe, the service
provider attribute "ThreadSafe" should be set to "true" during its
registration, as follows:

  put("SecureRandom.AlgName ThreadSafe", "true");

  or

  putService(new Service(this, "SecureRandom", "AlgName", className,
 null, Map.of("ThreadSafe", "true")));

{@code SecureRandom} will then call the applicable engine methods
without any synchronization.

--Sean

On 11/2/16 3:27 AM, Wang Weijun wrote:

Ping again.

There is an updated version at
http://cr.openjdk.java.net/~weijun/7004967/webrev.01/ with doc-only
changes.

Thanks
Max


On Aug 25, 2016, at 10:00 AM, Weijun Wang 
wrote:

Please review the enhancement at

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

Basically, we want SecureRandom to be more efficient by removing all
synchronized keywords from its public methods and let an
implementation to take care of thread-safety (We already did some in
JDK-8098581). On the other hand, we need to make sure that existing
implementations that have not synchronized correctly to behave just
as good as before.

Therefore a new Service Attribute "ThreadSafe" is introduced. If you
think your implementation is already thread-safe, set it to "true"
and SecureRandom will be happy. Otherwise, don't set it and
SecureRandom will continuously call your SecureRandomSpi engine
methods in synchronized blocks.

Thanks
Max