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-pl
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-u
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 S
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 javaHomeP
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=crypt
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 wr
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 imp
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
m
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
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 nee
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
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
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 upd
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
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?
17 matches
Mail list logo