On 8/25/2016 12:31 PM, Artem Smotrakov wrote:
Those tests which modify default JSSE parameters should be run in othervm mode.
But other tests which don't do that can be safely run in agent VM. This test
doesn't seem to modify any default JSSE parameter.
If this test get booted, other test
Those tests which modify default JSSE parameters should be run in othervm mode.
But other tests which don't do that can be safely run in agent VM. This test
doesn't seem to modify any default JSSE parameter.
Artem
- Original Message -
From: xuelei@oracle.com
To:
Hi All
Please take a look at
http://cr.openjdk.java.net/~weijun/8164705/webrev.00
From the beginning of JDK, FilePermission canonicalizes the input path
and use the result in implies() and equals(). This has been a big
performance hurt and leads to confusing results when symlinks are
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
On 8/25/2016 11:17 AM, Artem Smotrakov wrote:
Hi Xuelei,
Yes, I know that JSSE provider initializes only once. But I suppose that tests
which use default JSSE configuration (like this test) can be safely run in
agent VM. Am I missing something?
The default one can be customized. For
Hi Xuelei,
Yes, I know that JSSE provider initializes only once. But I suppose that tests
which use default JSSE configuration (like this test) can be safely run in
agent VM. Am I missing something?
Artem
- Original Message -
From: xuelei@oracle.com
To: artem.smotra...@oracle.com,
On 8/25/2016 7:57 AM, Sean Mullan wrote:
I posted an updated webrev:
http://cr.openjdk.java.net/~mullan/webrevs/8151893/webrev.0
I guess the link should be:
http://cr.openjdk.java.net/~mullan/webrevs/8151893/webrev.01/
Xuelei
I found an existing bug in the dsig implementation and wanted to
On 8/25/2016 9:27 AM, Artem Smotrakov wrote:
BTW, please run the test in othervm mode.
Why do you think it's necessary here? I don't see the test modifies
anything that may affect other tests running in the same JVM (for
example, system properties). Am I missing something?
It's not about the
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
Please review the enhancement at
http://cr.openjdk.java.net/~weijun/7004967/webrev.00/
Basically, we want SecureRandom to be more efficient by removing all
synchronized keywords from its public methods and let an implementation
to take care of thread-safety (We already did some in
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
Hi Xuelei,
Please see inline.
On 08/24/2016 06:10 PM, Xuelei Fan wrote:
On 8/25/2016 3:55 AM, Artem Smotrakov wrote:
Hi Svetlana,
Thank you for cleaning up this test. I have a couple of comments (mostly
about the original test).
1. I see that the test tries to connect to a server three
+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
On 8/25/2016 3:55 AM, Artem Smotrakov wrote:
Hi Svetlana,
Thank you for cleaning up this test. I have a couple of comments (mostly
about the original test).
1. I see that the test tries to connect to a server three times, but the
server accept only first connection, and then it stops. So
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
I posted an updated webrev:
http://cr.openjdk.java.net/~mullan/webrevs/8151893/webrev.0
I found an existing bug in the dsig implementation and wanted to fix it
with this change. There are 2 ways to register an element's ID attributes:
1. Using
Hi Svetlana,
Thank you for cleaning up this test. I have a couple of comments (mostly
about the original test).
1. I see that the test tries to connect to a server three times, but the
server accept only first connection, and then it stops. So test cases
#2-3 fail just because the
Please review this fix to add a new security property that allows you to
configure the individual restrictions that are enabled by the XML
Signature secure validation mode.
bug: https://bugs.openjdk.java.net/browse/JDK-8151893
webrev:
Hello,
please review this test bug fix. Test failed because of staled threads
left after execution.
Added try-with-resources statements to make sure test closes it's
resources. Also as test is overall quite old-fashioned I've done some
refactoring (hope now it looks better).
JBS:
Thanks for the review Xuelei. OK - I'll drop the 'password' reference
then and push the changes.
! throw new BadPaddingException("Given final block
not " +
! "properly padded. Such issues could arise if a bad
key " +
! "is used
Hi,
Please review the patch for "sun/security/krb5/auto/Unreachable.java fails with
Timeout error"
JBS: https://bugs.openjdk.java.net/browse/JDK-8015595
Webrev: http://cr.openjdk.java.net/~ssahoo/8015595/webrev.00/
Description:
When a KDC port is unreachable, Kerberos login module
On 8/24/2016 7:02 PM, Seán Coffey wrote:
On 22/08/16 11:06, Xuelei Fan wrote:
Minor comments:
CipherCore.java
---
"... could arise if a bad key or password is used during decryption."
"password" may be confusing for some user cases. This could also
happen if bad key used for
On 22/08/16 11:06, Xuelei Fan wrote:
Minor comments:
CipherCore.java
---
"... could arise if a bad key or password is used during decryption."
"password" may be confusing for some user cases. This could also
happen if bad key used for encryption. I may just say "could arise if
23 matches
Mail list logo
