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

[Bradford Wetmore]

http://cr.openjdk.java.net/~wetmore/8061842/webrev.04/

On 8/25/2016 8:05 PM, Weijun Wang wrote:

Can you add a new @run line which is the getNameCount()==1 but
getParent() != policyPath case?

+ * @run main/othervm TestUnlimited /unlimited exception


I think I finally developed a stable cross-platform case for this case. 
I've added this case and "unlimited/", which is an acceptable value.


On 8/26/2016 8:57 AM, Sean Mullan wrote:
> On 08/24/2016 08:21 PM, Bradford Wetmore wrote:
>> Sean Mullan wrote:
>>
>>  > What about setting the default value to "limited"? And then this
>>  > would only be changed to "unlimited" if the build --enable-unlimited-
>>  > crypto option is specified?
>>
>> I could, but I'm concerned that a build with --enabled-unlimited-crypto
>> would expect that the compiled-in version default would also be
>> unlimited and would be surprised with limited.
>>
>> Upon Max's suggestion above, I've changed the name of the marker to
>> "crypto.policy=crypto.policydir-tbd."  Does that work for you?
>
> Not really.
>
> Why not just leave the property unset (or commented out)? That seems
> more intuitive to me. What if the placeholder value accidentally never
> gets replaced?

If the value is unset, commented out, or set to a directory value that 
doesn't exist (e.g. crypto.policydir-tbd), JCE will throw a 
ExceptionInInitializerError on first usage.  If the rewriting script 
somehow doesn't get called as part of the build, then 
security.provider.tbd will likely also cause problems.


I may just not be understanding your concern.

> Anyway, if time is of the essence, go with what you have. This is not a
> significant issue.

2pm...(possible fallback to Monday if there aren't any PIT failures)

Brad

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

[Sean Mullan]

On 08/24/2016 08:21 PM, Bradford Wetmore wrote:

Sean Mullan wrote:

 > What about setting the default value to "limited"? And then this
 > would only be changed to "unlimited" if the build --enable-unlimited-
 > crypto option is specified?

I could, but I'm concerned that a build with --enabled-unlimited-crypto
would expect that the compiled-in version default would also be
unlimited and would be surprised with limited.

Upon Max's suggestion above, I've changed the name of the marker to
"crypto.policy=crypto.policydir-tbd."  Does that work for you?


Not really.

Why not just leave the property unset (or commented out)? That seems 
more intuitive to me. What if the placeholder value accidentally never 
gets replaced?


Anyway, if time is of the essence, go with what you have. This is not a 
significant issue.


--Sean

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

[Weijun Wang]

Can you add a new @run line which is the getNameCount()==1 but 
getParent() != policyPath case?


+ * @run main/othervm TestUnlimited /unlimited exception

No other comment.

On 8/26/2016 6:56, Bradford Wetmore wrote:

Last call:

http://cr.openjdk.java.net/~wetmore/8061842/webrev.03/

Thanks Sean for pointing out my new NPE I just introduced! ("Maybe add a
null check to be cleaner?")  Drat!  I would add a new test case, but
Security.setProperty() doesn't allow for "null."


I always wanted a Security::clearProperty().

--Max

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

[Bradford Wetmore]

Last call:

http://cr.openjdk.java.net/~wetmore/8061842/webrev.03/

Changes from .02:

added null check for cryptoPolicyProperty
renamed javaHomePolicyPath
tweaked exception wording "files in"
added test for empty string ("").


On 8/24/2016 6:22 PM, Weijun Wang wrote:

+Path javaHomePath = Paths.get(javaHomeProperty, "conf",
"security",
+"policy").normalize();

This is not javaHomePath, but policyPath.


Renamed as javaHomePolicyPath.


You added "cryptoPolicyProperty" to some exceptions, but the exception
titles are "Unexpected jurisdiction policy filename found: " and
"Couldn't parse jurisdiction policy files: ". cryptoPolicyProperty is
not file(s). Maybe "... file(s) in " + cryptoPolicyProperty?


Sure.  Sounds good.

Tony wrote:
> So by having no crypto.policy defined we have no JCA?

With no crypto.policy, that shuts down the JceSecurity init, and the app 
will exit with an ExceptionInInitializerError, like it does if the 
policy files are missing today.


Thanks Sean for pointing out my new NPE I just introduced! ("Maybe add a 
null check to be cleaner?")  Drat!  I would add a new test case, but 
Security.setProperty() doesn't allow for "null."


> Does that mean no
> operations at all (No MessageDigest, etc) or no restrictable crypto
> ops?

Recall that our JCA/JCE Permissions model is based on positive 
permission model checks.  It would mean no CryptoPermissions would be 
created, thus any operation that needs a CryptoPermissions (implies()) 
would fail.  So if you were somehow able to get the system to have no 
policy, there would be no Permissions granted to do any JCE operations.



As an aside, it would only fail JCE (Cipher/Mac/KeyAgreement), JCA would 
be unaffected as it doesn't use permissions.


> Since we know a limited number of countries have import issues, can we
> make no crypto.policy property defined as unlimited policy?  Defining
> the property would be for only limiting the access.  We could get rid of
> the unlimited policy file and just ship a limited policy file.

I'm very hesitant to do that, we need to be limited by default.

On 8/25/2016 6:56 AM, Sean Coffey wrote:
> I missed the "crypto.policy=crypto.policydir-tbd" approach in 1st
> revision. Isn't it going to confuse people studying the code ? This
> value gets replaced at build time - right ?

Yes.

> What about changing it to
> something like :
> "crypto.policy=$crypto.policydir-tbd //replaced at build time"
>
> and having the make files search for that string instead ? I think it
> makes the intent more obvious.

We're doing the same thing with "tbd" during the provider slot 
assignment. I'd like to keep it somewhat similar.


Brad




No other comment.

Thanks
Max

On 8/25/2016 8:21, Bradford Wetmore wrote:

Max/SeanC/SeanM,

The latest update:

http://cr.openjdk.java.net/~wetmore/8061842/webrev.02/

On 8/17/2016 9:26 PM, Wang Weijun wrote:

Before this change, you require default policy in neither export nor
import to be empty but do not care about the getMinimum() result. In
this change, you make sure the final result is not empty. I assume
this is a fix?


I made the change to allow for our traditional (default) export/import
mechanism, but other additional styles could be added/used.  Since we no
longer sign, distros are free to edit, add and/or remove files.  But
before doing any JCE operation, the environment needs to grant
something, otherwise there are no perms and no JCE available.


283 // Did we find a default perms?

What does this line mean?


I've moved to the right position in the file.  I meant did we find a
default perms file, vs an exempt.


296 // This should never happen

But you can still print out the file name.


I'm concerned that the exception might print out the entire path instead
of just the filename, which would include java.home and probably should
not be made available.


Can you rename policydir-tbd to something else? I am afraid it will be
confused with policy.url.1 etc.


Changed to:  crypto.policydir-tbd?


The original README.TXT in unlimited says "are exportable from the
United States." and you have "is exportable." now. Is this intended?
(IANAL)


Changed.


TestUnlimited.java:
45 "// Use the AES are the test Cipher", you mean "Use AES as the test
Cipher"?
51 "throw new Exception ("Unlimited policy is NOT active");". No space
before "(".


Fixed.

Sean Mullan wrote:

 > What about setting the default value to "limited"? And then this
 > would only be changed to "unlimited" if the build --enable-unlimited-
 > crypto option is specified?

I could, but I'm concerned that a build with --enabled-unlimited-crypto
would expect that the compiled-in version default would also be
unlimited and would be surprised with limited.

Upon Max's suggestion above, I've changed the name of the marker to
"crypto.policy=crypto.policydir-tbd."  Does that work for you?

 > Instead of throwing an exception here, I wonder if it 

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

[Sean Coffey]

Looks good Brad. One comment :

You might hit an NPE here but I guess the Exception handling in the 
parent call would handle it :


JceSecurity.java :
 254 if (Paths.get(cryptoPolicyProperty).getNameCount() != 1) {

Maybe add a null check to be cleaner ?

I missed the "crypto.policy=crypto.policydir-tbd" approach in 1st 
revision. Isn't it going to confuse people studying the code ? This 
value gets replaced at build time - right ? What about changing it to 
something like :

"crypto.policy=$crypto.policydir-tbd //replaced at build time"

and having the make files search for that string instead ? I think it 
makes the intent more obvious.


Regards,
Sean.

On 25/08/2016 01:21, Bradford Wetmore wrote:

Max/SeanC/SeanM,

The latest update:

http://cr.openjdk.java.net/~wetmore/8061842/webrev.02/

On 8/17/2016 9:26 PM, Wang Weijun wrote:
Before this change, you require default policy in neither export nor 
import to be empty but do not care about the getMinimum() result. In 
this change, you make sure the final result is not empty. I assume 
this is a fix?


I made the change to allow for our traditional (default) export/import 
mechanism, but other additional styles could be added/used.  Since we 
no longer sign, distros are free to edit, add and/or remove files.  
But before doing any JCE operation, the environment needs to grant 
something, otherwise there are no perms and no JCE available.



283 // Did we find a default perms?

What does this line mean?


I've moved to the right position in the file.  I meant did we find a 
default perms file, vs an exempt.



296 // This should never happen

But you can still print out the file name.


I'm concerned that the exception might print out the entire path 
instead of just the filename, which would include java.home and 
probably should not be made available.


Can you rename policydir-tbd to something else? I am afraid it will 
be confused with policy.url.1 etc.


Changed to:  crypto.policydir-tbd?

The original README.TXT in unlimited says "are exportable from the 
United States." and you have "is exportable." now. Is this intended? 
(IANAL)


Changed.


TestUnlimited.java:
45 "// Use the AES are the test Cipher", you mean "Use AES as the 
test Cipher"?
51 "throw new Exception ("Unlimited policy is NOT active");". No 
space before "(".


Fixed.

Sean Mullan wrote:

 > What about setting the default value to "limited"? And then this
 > would only be changed to "unlimited" if the build --enable-unlimited-
 > crypto option is specified?

I could, but I'm concerned that a build with 
--enabled-unlimited-crypto would expect that the compiled-in version 
default would also be unlimited and would be surprised with limited.


Upon Max's suggestion above, I've changed the name of the marker to 
"crypto.policy=crypto.policydir-tbd."  Does that work for you?


 > Instead of throwing an exception here, I wonder if it would make more
 > sense to assume a default value of "limited" if the property is not
 > set or is empty.

We could, but see above.

Sean Coffey wrote:

> Please include the exception 'e' in your last exception here.

Again, I'm concerned about outputting java.home, so I'm just going to 
output the final directory name.


> 3. Test case.
>
> The TestUnlimited.java testcase seems to be lacking. Do you want to
> test other values for crypto.policy ? 'limited' would be one.
> Throwing in some dummy value would also be good so that the exception
> handling code gets exercised.

Done.

 * @run main/othervm TestUnlimited limited fail
 * @run main/othervm TestUnlimited unlimited pass
 * @run main/othervm TestUnlimited NosuchDir exception
 * @run main/othervm TestUnlimited . exception
 * @run main/othervm TestUnlimited /tmp/unlimited exception
 * @run main/othervm TestUnlimited ../policy/unlimited exception
 * @run main/othervm TestUnlimited ./unlimited exception

> It needs to be run in ovm mode since you're setting a Security
> property.

Yes, good catch.

Brad

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

[Anthony Scarpino]

Yuck lawyers :-)

I think the lawyers have already answered.  The huge explanation in the 
java.security file covers our responsibilities and where the user's 
responsibilities starts.  I believe what I'm talking about is just 
implementation details.


Tony

On 08/24/2016 07:08 PM, Weijun Wang wrote:

I guess we need a lawyer to answer this question. :-)

On 8/25/2016 9:58, Anthony Scarpino wrote:

So by having no crypto.policy defined we have no JCA?  Does that mean no
operations at all (No MessageDigest, etc) or no restrictable crypto ops?

Since we know a limited number of countries have import issues, can we
make no crypto.policy property defined as unlimited policy?  Defining
the property would be for only limiting the access.  We could get rid of
the unlimited policy file and just ship a limited policy file.

Tony

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

[Weijun Wang]

I guess we need a lawyer to answer this question. :-)

On 8/25/2016 9:58, Anthony Scarpino wrote:

So by having no crypto.policy defined we have no JCA?  Does that mean no
operations at all (No MessageDigest, etc) or no restrictable crypto ops?

Since we know a limited number of countries have import issues, can we
make no crypto.policy property defined as unlimited policy?  Defining
the property would be for only limiting the access.  We could get rid of
the unlimited policy file and just ship a limited policy file.

Tony

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

[Anthony Scarpino]

On 08/24/2016 05:21 PM, Bradford Wetmore wrote:
[...]


Sean Mullan wrote:

  > What about setting the default value to "limited"? And then this
  > would only be changed to "unlimited" if the build --enable-unlimited-
  > crypto option is specified?

I could, but I'm concerned that a build with --enabled-unlimited-crypto
would expect that the compiled-in version default would also be
unlimited and would be surprised with limited.

Upon Max's suggestion above, I've changed the name of the marker to
"crypto.policy=crypto.policydir-tbd."  Does that work for you?


So by having no crypto.policy defined we have no JCA?  Does that mean no 
operations at all (No MessageDigest, etc) or no restrictable crypto ops?


Since we know a limited number of countries have import issues, can we 
make no crypto.policy property defined as unlimited policy?  Defining 
the property would be for only limiting the access.  We could get rid of 
the unlimited policy file and just ship a limited policy file.


Tony

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

[Weijun Wang]

+Path javaHomePath = Paths.get(javaHomeProperty, "conf", "security",
+"policy").normalize();

This is not javaHomePath, but policyPath.

You added "cryptoPolicyProperty" to some exceptions, but the exception 
titles are "Unexpected jurisdiction policy filename found: " and 
"Couldn't parse jurisdiction policy files: ". cryptoPolicyProperty is 
not file(s). Maybe "... file(s) in " + cryptoPolicyProperty?


No other comment.

Thanks
Max

On 8/25/2016 8:21, Bradford Wetmore wrote:

Max/SeanC/SeanM,

The latest update:

http://cr.openjdk.java.net/~wetmore/8061842/webrev.02/

On 8/17/2016 9:26 PM, Wang Weijun wrote:

Before this change, you require default policy in neither export nor
import to be empty but do not care about the getMinimum() result. In
this change, you make sure the final result is not empty. I assume
this is a fix?


I made the change to allow for our traditional (default) export/import
mechanism, but other additional styles could be added/used.  Since we no
longer sign, distros are free to edit, add and/or remove files.  But
before doing any JCE operation, the environment needs to grant
something, otherwise there are no perms and no JCE available.


283 // Did we find a default perms?

What does this line mean?


I've moved to the right position in the file.  I meant did we find a
default perms file, vs an exempt.


296 // This should never happen

But you can still print out the file name.


I'm concerned that the exception might print out the entire path instead
of just the filename, which would include java.home and probably should
not be made available.


Can you rename policydir-tbd to something else? I am afraid it will be
confused with policy.url.1 etc.


Changed to:  crypto.policydir-tbd?


The original README.TXT in unlimited says "are exportable from the
United States." and you have "is exportable." now. Is this intended?
(IANAL)


Changed.


TestUnlimited.java:
45 "// Use the AES are the test Cipher", you mean "Use AES as the test
Cipher"?
51 "throw new Exception ("Unlimited policy is NOT active");". No space
before "(".


Fixed.

Sean Mullan wrote:

 > What about setting the default value to "limited"? And then this
 > would only be changed to "unlimited" if the build --enable-unlimited-
 > crypto option is specified?

I could, but I'm concerned that a build with --enabled-unlimited-crypto
would expect that the compiled-in version default would also be
unlimited and would be surprised with limited.

Upon Max's suggestion above, I've changed the name of the marker to
"crypto.policy=crypto.policydir-tbd."  Does that work for you?

 > Instead of throwing an exception here, I wonder if it would make more
 > sense to assume a default value of "limited" if the property is not
 > set or is empty.

We could, but see above.

Sean Coffey wrote:


Please include the exception 'e' in your last exception here.


Again, I'm concerned about outputting java.home, so I'm just going to
output the final directory name.


3. Test case.

The TestUnlimited.java testcase seems to be lacking. Do you want to
test other values for crypto.policy ? 'limited' would be one.
Throwing in some dummy value would also be good so that the exception
handling code gets exercised.


Done.

 * @run main/othervm TestUnlimited limited fail
 * @run main/othervm TestUnlimited unlimited pass
 * @run main/othervm TestUnlimited NosuchDir exception
 * @run main/othervm TestUnlimited . exception
 * @run main/othervm TestUnlimited /tmp/unlimited exception
 * @run main/othervm TestUnlimited ../policy/unlimited exception
 * @run main/othervm TestUnlimited ./unlimited exception


It needs to be run in ovm mode since you're setting a Security
property.


Yes, good catch.

Brad

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

[Bradford Wetmore]

Max/SeanC/SeanM,

The latest update:

http://cr.openjdk.java.net/~wetmore/8061842/webrev.02/

On 8/17/2016 9:26 PM, Wang Weijun wrote:

Before this change, you require default policy in neither export nor import to 
be empty but do not care about the getMinimum() result. In this change, you 
make sure the final result is not empty. I assume this is a fix?


I made the change to allow for our traditional (default) export/import 
mechanism, but other additional styles could be added/used.  Since we no 
longer sign, distros are free to edit, add and/or remove files.  But 
before doing any JCE operation, the environment needs to grant 
something, otherwise there are no perms and no JCE available.



283 // Did we find a default perms?

What does this line mean?


I've moved to the right position in the file.  I meant did we find a 
default perms file, vs an exempt.



296 // This should never happen

But you can still print out the file name.


I'm concerned that the exception might print out the entire path instead 
of just the filename, which would include java.home and probably should 
not be made available.



Can you rename policydir-tbd to something else? I am afraid it will be confused 
with policy.url.1 etc.


Changed to:  crypto.policydir-tbd?


The original README.TXT in unlimited says "are exportable from the United States." and 
you have "is exportable." now. Is this intended? (IANAL)


Changed.


TestUnlimited.java:
45 "// Use the AES are the test Cipher", you mean "Use AES as the test Cipher"?
51 "throw new Exception ("Unlimited policy is NOT active");". No space before 
"(".


Fixed.

Sean Mullan wrote:

 > What about setting the default value to "limited"? And then this
 > would only be changed to "unlimited" if the build --enable-unlimited-
 > crypto option is specified?

I could, but I'm concerned that a build with --enabled-unlimited-crypto 
would expect that the compiled-in version default would also be 
unlimited and would be surprised with limited.


Upon Max's suggestion above, I've changed the name of the marker to 
"crypto.policy=crypto.policydir-tbd."  Does that work for you?


 > Instead of throwing an exception here, I wonder if it would make more
 > sense to assume a default value of "limited" if the property is not
 > set or is empty.

We could, but see above.

Sean Coffey wrote:

> Please include the exception 'e' in your last exception here.

Again, I'm concerned about outputting java.home, so I'm just going to 
output the final directory name.


> 3. Test case.
>
> The TestUnlimited.java testcase seems to be lacking. Do you want to
> test other values for crypto.policy ? 'limited' would be one.
> Throwing in some dummy value would also be good so that the exception
> handling code gets exercised.

Done.

 * @run main/othervm TestUnlimited limited fail
 * @run main/othervm TestUnlimited unlimited pass
 * @run main/othervm TestUnlimited NosuchDir exception
 * @run main/othervm TestUnlimited . exception
 * @run main/othervm TestUnlimited /tmp/unlimited exception
 * @run main/othervm TestUnlimited ../policy/unlimited exception
 * @run main/othervm TestUnlimited ./unlimited exception

> It needs to be run in ovm mode since you're setting a Security
> property.

Yes, good catch.

Brad

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

[Sean Mullan]

On 08/17/2016 07:22 PM, Bradford Wetmore wrote:

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


Ok, but those are property names.

What about setting the default value to "limited"? And then this would 
only be changed to "unlimited" if the build --enable-unlimited-crypto 
option is specified?



I could change it to be delineated with <>:
"" 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
/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().


 253 // Sanity check the crypto.policy Security property.  Single
 254 // directory entry, no pseudo- or subdirectories.
 255 String cryptoPolicyDir = 
Security.getProperty("crypto.policy");

 256
 257 if (cryptoPolicyDir == null) {
 258 throw new SecurityException(
 259 "No cryptographic jurisdiction policy directory 
value");

 260 }

Instead of throwing an exception here, I wonder if it would make more 
sense to assume a default value of "limited" if the property is not set 
or is empty.


--Sean

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

[Seán Coffey]

Hi Brad,

nice to have this going in. Some comments.

1. Bug synopsis, can you edit it perhaps. "Introduce security property 
to control strong crypto" seems more descriptive.


2. Exception handling.

Alot of your new exceptions don't include context. That makes debugging 
more difficult than needs be.



+throw new SecurityException(
+"Invalid cryptographic jurisdiction policy directory value");
+if (!Files.isDirectory(path) || !Files.isReadable(path)) {
+throw new Exception("Can't read cryptographic policy directory");



+throw new SecurityException(
+"Unexpected jurisdiction policy filename found");



+} catch (Exception e) {
+throw new SecurityException(
+"Couldn't parse jurisdiction policy files");

Please include the exception 'e' in your last exception here.



+} catch (DirectoryIteratorException ex) {
+// I/O error encountered during the iteration,
+// the cause is an IOException
+throw new SecurityException(
+"Couldn't iterate through the jurisdiction policy files");
+}
Can you add the DirectoryIteratorException to the final exception that 
you're throwing ?


3. Test case.

The TestUnlimited.java testcase seems to be lacking. Do you want to test 
other values for crypto.policy ? 'limited' would be one. Throwing in 
some dummy value would also be good so that the exception handling code 
gets exercised.


It needs to be run in ovm mode since you're setting a Security property.

Regards,
Sean.

On 18/08/2016 05:26, Wang Weijun wrote:

Before this change, you require default policy in neither export nor import to 
be empty but do not care about the getMinimum() result. In this change, you 
make sure the final result is not empty. I assume this is a fix?

283 // Did we find a default perms?

What does this line mean?

296 // This should never happen

But you can still print out the file name.


Can you rename policydir-tbd to something else? I am afraid it will be confused 
with policy.url.1 etc.

The original README.TXT in unlimited says "are exportable from the United States." and 
you have "is exportable." now. Is this intended? (IANAL)

TestUnlimited.java:
45 "// Use the AES are the test Cipher", you mean "Use AES as the test Cipher"?
51 "throw new Exception ("Unlimited policy is NOT active");". No space before 
"(".

No other comment.

--Max


On Aug 18, 2016, at 7:22 AM, Bradford Wetmore  
wrote:

New webrev:

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

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

[Wang Weijun]

Before this change, you require default policy in neither export nor import to 
be empty but do not care about the getMinimum() result. In this change, you 
make sure the final result is not empty. I assume this is a fix?

283 // Did we find a default perms?

What does this line mean?

296 // This should never happen

But you can still print out the file name.


Can you rename policydir-tbd to something else? I am afraid it will be confused 
with policy.url.1 etc.

The original README.TXT in unlimited says "are exportable from the United 
States." and you have "is exportable." now. Is this intended? (IANAL)

TestUnlimited.java:
45 "// Use the AES are the test Cipher", you mean "Use AES as the test Cipher"?
51 "throw new Exception ("Unlimited policy is NOT active");". No space before 
"(".

No other comment.

--Max

> On Aug 18, 2016, at 7:22 AM, Bradford Wetmore  
> wrote:
> 
> New webrev:
> 
> https://bugs.openjdk.java.net/browse/JDK-8061842
> http://cr.openjdk.java.net/~wetmore/8061842/webrev.01/

Re: 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. /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 <>: 
"" 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 
/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
/lib/security to a series of subdirectories under a new
"policy" subdirectory in /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 /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

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

[Sean Mullan]

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/

18 specifically activated by updating the "crypto.policy" entry in the

s/entry/Security property/

33 Please see The Java(TM) Cryptography Architecture (JCA) Reference

Is "TM" really necessary here?

- 
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"?


- 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?


- 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 ""?

302 // I/O error encounted during the iteration,

s/encounted/encountered/

--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
/lib/security to a series of subdirectories under a new
"policy" subdirectory in /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 /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

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

[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 implement
something like a Fips-compliant runtime in terms of (yet another)
policy?


This policy is just for enforcing maximum JCE keysizes for import/export 
purposes, which has been there since pretty much Day 1 of JCE.  This is 
just repackaging existing policy, as the jigsaw team really wanted to 
get rid of the jar files.  JEP 220.


A FIPs matrix is a discussion for another release.


Related to that: are there any other useful uses for those jce policies?
(Never encounter them besides the restricted ciphers).


I don't think so.  I think for most cases, people are able to install 
the unlimited bundle and are done.


This was before my time, but I believe this was only to satisfy 
export/import requirements.



For things like
enforcing minimum security (FIPS, PCI-DSS, ...) the policy objects
should not only feature maximum keysizes, but also minimum sizes,
right? Same is true for denying weakening attributes and such. On the
other hand this greatly conflicts with the security properties already
existing (at least for JSSE).

You mail did not talk about signatures, will the new policies require
to be signed by a JCE certifiate (i.e. via Oracle) or can they be
customized without?


Customized without.


Will there be an option "use strongest available"? That way an JDK
upgrade (overwrite the files) will no longer be a problem as the
additional policy persists - but I still would need the system property
to activate it...


I would expect our limited/unlimited files/directories won't change. The 
contents have been static for years, but required the extra step of the 
download/replacement until earlier in JDK 9.


There have been 2-3 one-off policy file bundles generated over the last 
15 years (with even tighter restrictions), but ivery rare.


If you're modifying java.security, that is the only file you'll need for 
persistent policy going forward.  If you are creating your own 
directories, you'll of course need to copy those over too.


BTW, it's a Security property, not a java.lang.System property.

Brad



Gruss
Bernd


 Am Thu, 4 Aug 2016 12:35:21 -0700 schrieb 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 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 /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

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

[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?

Related to that: are there any other useful uses for those jce policies?
(Never encounter them besides the restricted ciphers). For things like
enforcing minimum security (FIPS, PCI-DSS, ...) the policy objects
should not only feature maximum keysizes, but also minimum sizes,
right? Same is true for denying weakening attributes and such. On the
other hand this greatly conflicts with the security properties already
existing (at least for JSSE).

You mail did not talk about signatures, will the new policies require
to be signed by a JCE certifiate (i.e. via Oracle) or can they be
customized without?

Will there be an option "use strongest available"? That way an JDK
upgrade (overwrite the files) will no longer be a problem as the
additional policy persists - but I still would need the system property
to activate it...

Gruss
Bernd


 Am Thu, 4 Aug 2016 12:35:21 -0700 schrieb 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 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 /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
> 

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

[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 
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 /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