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
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
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
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
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
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
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
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
+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
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
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
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
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
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:
-
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
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
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?
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
18 matches
Mail list logo
