On 5/14/2014 2:04 PM, Weijun Wang wrote:
What do you mean by detecting the platform? So if I find the file is
also used by NetBSD krb5 then I treat it as second and if not
millisecond?
Yes.
That's quite impossible. In my opinion, it all depends on
how the writer is educated, Java or some else.
The spec should be clear, and the writer should be well educated. It
cannot be a condition to update the implementation that the write is not
educated.
How is this unsafe, especially compared to if we don't fix it? The only
bad thing is that if someone wants to set the timeout to be less than
120 ms, now there will be no way to do it. But that should never happen,
right?
My concerns is that it might happen. 120ms is not a small number, and
120s is not a big number in some circumstances.
Alternatively, for better inerop, we can suggest to use explicit spec in
the configure instead of guess the what the spec is. Support two
default specs is really confusing.
Xuelei
My comment in the bug mentions we can support "5s", but then I realize
it dies not really solve the unit-less case.
Thanks
Max
------------------------------------------------------------------------
发件人: Xuelei Fan
发送时间: 2014/5/14 13:21
收件人: [email protected]
主题: Re: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout
asmsec instead of sec
This does not sound like a safe update to me. Is it possible to
detected the actual kdc_timeout spec (for example, using the known
platform) of the underlying configuration?
Xuelei
On 5/14/2014 8:38 AM, Weijun Wang wrote:
> Please review the code changes at
>
> http://cr.openjdk.java.net/~weijun/8036779/webrev.00/
>
> The problem is that Java treats kdc_timeout as milliseconds but others
> (NetBSD here) might treat it as seconds. With this code change, when the
> number is <= 120, it's seconds, otherwise, milliseconds.
>
> One exception would be that someone thinking NetBSD style could set it
> to 999 for a "maximum" timeout but the final result is less than 1
> second. In that case, we should advise him/her to set it to 99999999.
>
> Thanks
> Max
