Re: RFR: 8160655 Fix denyAfter and usage types for security properties

The two changes are connected, removing the key algorithm check in the second change is linked to changing the permits() in the first change. But I agree that this change is unnecessary.. I'm going to revert it back. thanks Tony On 01/26/2017 01:09 PM, Xuelei Fan wrote:

Re: RFR: 8160655 Fix denyAfter and usage types for security properties

I believe all comments are addressed in the below link http://cr.openjdk.java.net/~ascarpino/8160655/webrev.02/ Everything I didn't comment on inline below was because I hadn't posted an update-to-date webrev.01 at that time. Tony On 02/06/2017 12:17 PM, Sean Mullan wrote: Hi Tony, Here

Re: RFR [9] 8173708: Re-enable AES cipher with CFB128 mode for Ucrypto provider

Assuming that 15761286/7121679 is fixed in all of the Solaris versions we'll be supporting (as mentioned in 8173708), then this looks fine. Thanks, Brad On 1/31/2017 5:51 PM, Valerie Peng wrote: Hi Brad, Would you have time to review this trivial Ucrypto config file update? It's related

TlsRsaPremasterSecretParameterSpec

Hello Java Security Developers We had a discussion a year and a bit ago about the TlsRsaPremasterSecretParameterSpec being used in a way that doesn't seem to make sense. I've attached the email from 2015, but the same question has arisen. It seems that the JSSE is expecting RSA Ciphers

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

> On 1 Feb 2017, at 22:19, Vladimir Kozlov wrote: > > AOT tool jaotc does not run with SecurityManager. We assume it runs in secure > environment and it does not access any external resources. Great. Can I now consider this change reviewed and integrate it? -Doug

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

> On 1 Feb 2017, at 20:54, Sean Mullan wrote: > > Couple of comments: > > - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted > AllPermission and does not need an entry in default.policy. Thanks - I removed it. > - all internal APIs in the

Re: RFR : 8173783: IllegalArgumentException: jdk.tls.namedGroups

Thanks for the comments Brad and Bernd. I've incorporated them into a new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8173783.jdk9.v2/webrev/ Brad - I've tweaked your suggestion further to indicate if the default values were used. ! "Initialized [jdk.tls.namedGroups|default] list

Re: RFR 8173410: Add commented config line for jdk.security.provider.preferred

As I mentioned below, the RMI entry was merged from a closed repo into the middle of the disabled algorithms section. It was the merger's fault for not paying attention. I'm just trying to fix the problem.. Tony On 02/07/2017 11:21 AM, Bradford Wetmore wrote: Thanks for making the comment

RFR 8006259: Test example vectors from NIST SP 800-38A

This change adds a test which executes example vectors from NIST SP 800-38A to check AES in various modes of operation. The test pulls in all of the providers and runs the appropriate vectors for all supported modes of operation on each provider. It passes on all platforms on JPRT, and I

Re: RFR 8173410: Add commented config line for jdk.security.provider.preferred

Thanks for making the comment formating consistent. Why did you move the RMI Registry Serial Filter? Offhand, this seems gratuitous, and will make ift more difficult for folks trying to maintain a single or slightly modified java.security across release families. Looks good otherwise.

Re: RFR : 8173783: IllegalArgumentException: jdk.tls.namedGroups

Nit, I don't like the wording of 196-7. You have either jdk.tls.namedGroups or if not defined, you have the default values. In that case, this is going to print "Property defined: null" Maybe something along the lines of: "Initialized [jdk.tls.namedGroups|default] list contains " +

Re: RFR : 8173783: IllegalArgumentException: jdk.tls.namedGroups

Should it use Debug.println? Gruss Bernd -- http://bernd.eckenfels.net On Tue, Feb 7, 2017 at 7:51 PM +0100, "Xuelei Fan" wrote: Looks fine to me. Thanks, Xuelei On 2/7/2017 7:25 AM, Seán Coffey wrote: > The recent JDK-8148516 enhancement causes issue for

Re: RFR : 8173783: IllegalArgumentException: jdk.tls.namedGroups

Looks fine to me. Thanks, Xuelei On 2/7/2017 7:25 AM, Seán Coffey wrote: The recent JDK-8148516 enhancement causes issue for JDKs without EC support. It's primarily an issue for JDK 6u which doesn't have SunEC but this still needs to be fixed in all release families. bug report :

RFR : 8173783: IllegalArgumentException: jdk.tls.namedGroups

The recent JDK-8148516 enhancement causes issue for JDKs without EC support. It's primarily an issue for JDK 6u which doesn't have SunEC but this still needs to be fixed in all release families. bug report : https://bugs.openjdk.java.net/browse/JDK-8173783 webrev :

RE: [9] RFR: 8168423: Test Task: Custom system class loader + security manager + malformed policy file = recursive initialization

Hi Sean, Please find the updated webrev at: http://cr.openjdk.java.net/~ssahoo/8168075/webrev.01/ It includes the following changes, 1) valid.policy, uses 'grant codebase "executable jar path"'. 2) In ClassLoaderTest.java, @bug renamed from 8168423 to 8168075. 3) In ClassLoaderTest.java, the