On Jul 8, 2014, at 23:15, Xuelei Fan wrote:
> Looks fine to me.
>
> It would be nice to extend AlgorithmId.getStandardDigestName() to
> AlgorithmId.getStandardName() in the future.
The JDK8 version of fix for 7180907 already had AlgorithmId.getName() returning
the standard one.
--Max
>
> X
Webrev updated at phttp://cr.openjdk.java.net/~weijun/8049480/webrev.01/.
Thanks
Max
On Jul 9, 2014, at 0:45, Sean Mullan wrote:
> On 07/08/2014 10:37 AM, Wang Weijun wrote:
>> Please review the jdk7u-only code change at
>>
>> http://cr.openjdk.java.net/~weijun/8049480/webrev.00/
>>
>> The re
On 7/8/14, 5:33 PM, Valerie Peng wrote:
I modified the ProviderConfig class to skip providers when the
corresponding provider class failed during initiation time (e.g. lacking
certain permission). Thus, for tests which do not need/use crypto
providers, their test policy don't have to contain the
I modified the ProviderConfig class to skip providers when the
corresponding provider class failed during initiation time (e.g. lacking
certain permission). Thus, for tests which do not need/use crypto
providers, their test policy don't have to contain the entries for
crypto providers.
Than
Looks good, although do you know why you were able to remove the grant
AllPermission from so many of the test policy files without granting
additional specific permissions?
--Sean
On 07/07/2014 05:14 PM, Valerie Peng wrote:
Updated the webrev to include the updates of test policy files.
Also
Hi Max,
Here are my comments:
* KerberosKey
37: Did you mean to use @link instead of @see?
- several methods are now defined to throw IllegalStateExc, but you
(perhaps accidentally) removed the code that does that (ex: getKeyType).
* KerberosTicket
352-3: put braces around the if (destroye
When looking through the code and running regression tests as well as
some of my own sample programs, SunPKCS11 needs permission to access
"sun.security.pkcs11.allowSingleThreadedModules" property.
As for other providers, they seem fine without the PropertyPermission.
But the required permis
Looks good to me.
--Sean
On 07/08/2014 01:22 PM, Seán Coffey wrote:
Looking to backport this fix to the JDK 7u code line. The code was
refactored in JDK 8 but the change is still easily applied.
No issues with JPRT test run.
bug ID: https://bugs.openjdk.java.net/browse/JDK-8021804
webrev : htt
Looking to backport this fix to the JDK 7u code line. The code was
refactored in JDK 8 but the change is still easily applied.
No issues with JPRT test run.
bug ID: https://bugs.openjdk.java.net/browse/JDK-8021804
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8021804.7u/webrev/
JDK 8 chang
On 07/08/2014 10:37 AM, Wang Weijun wrote:
Please review the jdk7u-only code change at
http://cr.openjdk.java.net/~weijun/8049480/webrev.00/
The reason is that the jdk7u version [1] of fix for JDK-8049480 is just a hack and not as
powerful as its jdk8 sibling [2] and now I'll have to apply
Looks fine to me.
It would be nice to extend AlgorithmId.getStandardDigestName() to
AlgorithmId.getStandardName() in the future.
Xuelei
On 7/8/2014 10:37 PM, Wang Weijun wrote:
> Please review the jdk7u-only code change at
>
> http://cr.openjdk.java.net/~weijun/8049480/webrev.00/
>
> The rea
Max,
These changes look fine. Just a couple of minor comments:
L130 in Client.java appears to be superfluous now.
The comment at L186 in Server.java might probably should
be removed or else expanded upon.
Thanks
Michael
On 23/06/14 09:09, Wang Weijun wrote:
Ping again.
On Jun 12, 2014, at
Please review the jdk7u-only code change at
http://cr.openjdk.java.net/~weijun/8049480/webrev.00/
The reason is that the jdk7u version [1] of fix for JDK-8049480 is just a hack
and not as powerful as its jdk8 sibling [2] and now I'll have to apply the
jdk7u jar signature "hack" to timestamp s
If the first UDP response can be back in a second then there is no extra
workload. This should be the most common case since Kerberos is usually used in
an enterprise environment with a high network speed. In most cases, the re-sent
of a request is due to failed KDCs or even false settings which
Looks fine to me.
The old code looks a little bit hard to understand to me.
Xuelei
On 7/8/2014 9:15 PM, Sean Mullan wrote:
> Please review my fix for JDK-8049244:
>
> http://cr.openjdk.java.net/~mullan/webrevs/8049244/webrev.00/
>
> This is a direct port of the corresponding fix from Apach
Please review my fix for JDK-8049244:
http://cr.openjdk.java.net/~mullan/webrevs/8049244/webrev.00/
This is a direct port of the corresponding fix from Apache Santuario. No
regression test since this is a performance related fix. However, the
customer that reported this to the Apache Santu
Missed the security-dev list.
On 7/7/2014 10:39 AM, Xuelei Fan wrote:
> I have not read the fix. I was just wondering that this fix save the
> wait time, but increase the networking traffics, and increase the
> workload of KDC servers. I think the KDC timeout should be corner cases
> for TCP, an
On Jul 8, 2014, at 17:20, Michael-O <1983-01...@gmx.net> wrote:
> Hi Max,
>
> are you going to backport this to Java 7?
I would be glad to do that. But now I still cannot find anyone code reviewing
it for JDK 9.
> We are suffering from this on a regular basis because several KDCs are faulty
Hi Max,
are you going to backport this to Java 7? We are suffering from this on a
regular basis because several KDCs are faulty returned by DNS SRVs. 30 s is not
acceptable. Moreover, why is the property krb5.kdc.bad.policy not documented
publically?
Thanks,
Michael
19 matches
Mail list logo
