A new version at
http://cr.openjdk.java.net/~weijun/8131350/webrev.01/
"public" modifiers of methods/fields inside Prin/Perm and child classes
removed.
Thanks
Max
On 07/16/2015 09:43 PM, Weijun Wang wrote:
Hi All
Please take a look at
http://cr.openjdk.java.net/~weijun/8131350/webre
The change looks fine.
That said, is CodeSource's hashCode/equals used somewhere else? I mean,
can we directly update them?
Thanks
Max
On 07/18/2015 05:32 AM, Sean Mullan wrote:
One of the changesets for JEP 232 (Improve Secure Application
Performance) introduced a regression in the Protecti
Oh, I didn't see you clear the properties. I thought you reassign
correct ones still using system properties. Sorry.
Then there is nothing wrong.
Thanks
Max
On 07/18/2015 07:30 AM, Artem Smotrakov wrote:
Hi Max,
Yes, it is possible to write it manually, but content of krb5 file
should be lik
Hi Max,
Yes, it is possible to write it manually, but content of krb5 file
should be like the following:
[libdefaults]
default_realm = TEST.REALM
max_retries = 1
[realms]
TEST.REALM = {
kdc = localhost: 12345
}
Then, the test overrides kdc/realm with system properties. But finally
at li
May I request you to review two new tests added to check SealedObject
with different ciphers.
Bug: https://bugs.openjdk.java.net/browse/JDK-8048624
Webrev: http://cr.openjdk.java.net/~rhalade/8048624/webrev/
Thanks,
Rajan
Although the java.security.krb5.kdc/realm system properties are able to
override the values inside krb5.conf, it is better to write one without
realm/kdc info at all. So, instead of
60 KDC.saveConfig(KRB5_CONF_FILENAME, kdc, "max_retries = 1");
How about just manually write
Files
One of the changesets for JEP 232 (Improve Secure Application
Performance) introduced a regression in the ProtectionDomain cache used
by SecureClassLoader. The HashMap key needs to also check the
Certificates of the CodeSource (as well as the location); otherwise 2
CodeSources from the same loc
Hi, Max.
Thanks for taking the time to review.
Regards,
iris
-Original Message-
From: Weijun Wang
Sent: Wednesday, July 08, 2015 8:57 PM
To: Iris Clark; security-dev@openjdk.java.net
Subject: Re: RFR: (s) 8130696: Security Providers need to have their version
numbers updated for JDK 9
Hi, Sean.
Sorry for the delayed response.
Thanks for your review. Great catch! I thought I'd checked the output for all
of the failing security tests, but it looks like I missed that.
I've created and tested a new changeset which addresses that problem. The
changeset is off of verona/stage
Hi, Valerie.
Sorry for the delayed response.
Thanks for reviewing.The original webrev was based off of verona/stage
which was synch'd to jdk9-b70. The file you reference wasn't in the repository
yet.
Since that time, verona/stage has been sync'd with jdk9-b72 . Here's the new
Sorry for not being explicit about the changes that went into webrev.2,
but I've listed them below:
* The StatusResponseManager to do cache checking from the main thread
rather than a worker thread
* A fix in ServerHandshaker's selection of the CertStatusReqItemV2
where I wasn't properly
Hi Max,
Please see an updated webrev:
http://cr.openjdk.java.net/~asmotrak/8075297/webrev.03/
Artem
On 07/16/2015 11:31 PM, Wang Weijun wrote:
I think it it enough to add a "max_retries = 1" to [libdefaults] of krb5.conf,
and left default timeout value for the test. Please take a look at upd
12 matches
Mail list logo
