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

[Bradford Wetmore]

New webrev:

https://bugs.openjdk.java.net/browse/JDK-8061842
http://cr.openjdk.java.net/~wetmore/8061842/webrev.01/

On 8/10/2016 11:19 AM, Sean Mullan wrote:
> Hi Brad,
>
> Looks pretty good. You should also send this to build-dev to review the
> Makefile changes. Just a few comments:
>
> - src/java.base/share/conf/security/policy/README.txt
>
> 17 contain no restrictions on cryptographic strengths, but they must
>
> s/must/must be/

Ok.

> 18 specifically activated by updating the "crypto.policy" entry in the
>
> s/entry/Security property/

Ok.  I've updated to:

---begin---
specifically activated by updating the "crypto.policy" Security property
(e.g. <java-home>/conf/security/java.security) to point to the 
appropriate directory.
----end---

> 33 Please see The Java(TM) Cryptography Architecture (JCA) Reference
>
> Is "TM" really necessary here?

It was required in previous versions of the unlimited crypto policy 
bundle.  We could run it by PM if you feel we should.

> src/java.base/share/conf/security/policy/unlimited/default_US_export.policy
>
> 1 // Manufacturing policy file.
>
> The term "Manufacturing" is odd. Can we just say this is the "Default
> local policy file"?

Sure.

> - src/java.base/share/conf/security/java.security
>
> 854 crypto.policy=policydir-tbd
>
> The policydir-tbd value is a little confusing in that it isn't a real
> value. What about just setting this to the empty string?

It's a similar marker for the string replacement like was done for 
security.provider.tbd.  I could change it to be delineated with <>: 
"<policydir-tbd>" if you like?

> - src/java.base/share/classes/javax/crypto/JceSecurity.java
>
>  255         String cryptoPolicyDir =
> Security.getProperty("crypto.policy");
>  256         Path cryptoPolicyPath = Paths.get(cryptoPolicyDir);
>
> What happens if crypto.policy is not set or is set to ""?

Good catch.  Not set would NPE, "" would simply look at 
<java-home>/conf/security/policy and fail to iterate the directory if no 
files were actually there.  I've added code for both those conditions, 
and also switched to use Path.resolve().

> 302             // I/O error encounted during the iteration,
>
> s/encounted/encountered/

Thanks!

Brad


> --Sean
>
> On 08/04/2016 03:35 PM, Bradford Wetmore wrote:
>> 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
>> <java-home>/lib/security to a series of subdirectories under a new
>> "policy" subdirectory in <java-home>/conf/security.  Each subdirectory
>> within that directory will represent a complete policy configuration.
>> The existing jar files will be split into flat text files such that the
>> current/existing policies remain.
>>
>> The default set of policy files (i.e. directory) is configured using a
>> new java.security.Security property called "crypto.policy" which will be
>> added to the <java-home>/conf/security/java.security file.  The default
>> initial options are "limited" or "unlimited", however additional
>> directories could potentially be created that specify other
>> as-yet-unknown policies.
>>
>> The default value of this property will be "limited" which corresponds
>> to our current policy for JRE/JDK export/import around the world.
>> However, the build respects the following "configure" option:
>>
>>     --enable-unlimited-crypto
>>                         Enable unlimited crypto policy [disabled]
>>
>> Within the directory, our implementation will look for files using the
>> standard filename prefix above ("default_" or "exempt_"), thus new
>> additional policy restrictions/abstractions can be added with a simple
>> file addition.
>>
>> Brad
>>