Re: [9] RFR 8154113: java.security.AccessControlException: access denied ("java.security.SecurityPermission" "authProvider.SunMSCAPI")

2016-08-04 Thread Sean Mullan
On 08/04/2016 12:42 AM, Mandy Chung wrote: A passing comment: The test can simply specify @modules jdk.crypto.mscapi and this test will only run when jdk.crypto.mscapi is present; in other words, line 45-48 are no longer needed. Does that also mean line 27 can be removed: 27 * @requires os

Re: [9] RFR 8154113: java.security.AccessControlException: access denied ("java.security.SecurityPermission" "authProvider.SunMSCAPI")

2016-08-04 Thread Sean Mullan
Looks good. --Sean On 08/03/2016 07:15 PM, Valerie Peng wrote: Sure, webrev updated: http://cr.openjdk.java.net/~valeriep/8154113/webrev.01/ Thanks, Valerie On 8/3/2016 6:09 AM, Sean Mullan wrote: Hi Valerie, Can you also clean up the noaccess.policy and access.policy files and remove the p

RFR: 8061842: Package jurisdiction policy files as something other than JAR

2016-08-04 Thread Bradford Wetmore
https://bugs.openjdk.java.net/browse/JDK-8061842 http://cr.openjdk.java.net/~wetmore/8061842/webrev.00/ The proposal is to move the configuration files from the jar files in /lib/security to a series of subdirectories under a new "policy" subdirectory in /conf/security. Each subdirectory with

Re: RFR: 8061842: Package jurisdiction policy files as something other than JAR

2016-08-04 Thread Bernd Eckenfels
Hello, I am glad as a user that I am only annoyed by the limited policies and that I do not have to actually implement features to restrict my software. :) However your mail reminded me: will it be a good idea to implement something like a Fips-compliant runtime in terms of (yet another) policy?

Re: RFR: 8061842: Package jurisdiction policy files as something other than JAR

2016-08-04 Thread Bradford Wetmore
On 8/4/2016 1:41 PM, Bernd Eckenfels wrote: Hello, I am glad as a user that I am only annoyed by the limited policies and that I do not have to actually implement features to restrict my software. :) You are indeed fortunate. :) However your mail reminded me: will it be a good idea to imp

[9] RFR 8157579: com/sun/crypto/provider/Mac/MacClone.java failed on solaris12(sparcv9 and x86)

2016-08-04 Thread Valerie Peng
Anyone has time to review this fix? The code change is in only one file and straightforward if you agree with the approach. Starting S11.3 and S12, OracleUcrypto provider switched to new Ucrypto APIs for message digest operations and there is no clone support. This affects the MAC impls of SunJ

Re: [9] RFR 8154113: java.security.AccessControlException: access denied ("java.security.SecurityPermission" "authProvider.SunMSCAPI")

2016-08-04 Thread Mandy Chung
> On Aug 4, 2016, at 7:20 AM, Sean Mullan wrote: > > On 08/04/2016 12:42 AM, Mandy Chung wrote: >> A passing comment: >> >> The test can simply specify @modules jdk.crypto.mscapi and this test will >> only run when jdk.crypto.mscapi is present; in other words, line 45-48 are >> no longer need