an rely on, and no need to look at whether the
>> offset of the security buffer is zero.
>>
>> So it does look safer to return a new byte[0] right inside
>> readSecurityBuffer(int offset) when the offset is zero.
>>
>> Thanks
>> Max
>>
>>&
The fix looks fine to me.
The readSecurityBuffer() is correct. When there is no offset, there is no
security buffer at all. When the length is zero, the security buffer is an
empty byte array.
Here I think the customer encountered a server-side error. The fix is for
interop with this abnorma
> On Oct 28, 2015, at 4:56 AM, Mark Sheppard wrote:
>
> dynamic update of host / ip mappings updates are accommodated as seen per the
> tests
> http://cr.openjdk.java.net/~msheppar/8134577/webrev/test/sun/net/InetAddress/nameservice/simple/DefaultCaching.java.sdiff.html
> http://cr.openjdk.java
I see a lot of krb5 tests modified.
Basically, the NameServiceDescriptor inside KDC.java maps everything to
localhost except for one (I guess Artem invented the 2nd feature). Can we
expand the grammar a little bit to support this? For example:
not.existing.host UnknownHostException
* 127.0.
Let's go back to the bug description:
But no fallback happens if:
1. an HTTP server supports both Negotiate (via Kerberos) and Basic
authentication schemes
2. first, a user provides correct Kerberos credentials, and a connection is
successfully established with Negotiate scheme
3. then, a us
> On Oct 7, 2015, at 11:51 PM, Artem Smotrakov
> wrote:
>
> Hi Max,
>
> HttpURLConnection obtains credentials for HTTP authentication from
> Authenticator [1] implementation. Only one authenticator can be set in JVM
> instance. It can have built-in credentials, or do some interactions with u
I will look into this. Busy on something else at the moment.
Do you think this would happen in reality? There weren't a lot of fallback in
HTTP auth, IMO, is that because in most cases username and password are the
same for all schemes, and if one fails, we believe the pair is wrong and there
i
non-public APIs.
>
> Here it is with that change; please take a look:
> http://cr.openjdk.java.net/~juh/8073430/02/
>
> Thanks,
> Jason
>
> On 03/05/2015 09:32 PM, Wang Weijun wrote:
>> What is the policy for deprecating a non-public-API method?
>>
What is the policy for deprecating a non-public-API method?
> On Mar 6, 2015, at 13:30, Wang Weijun wrote:
>
> Instead of adding @SupressWarnings to a method, can we add @Deprecated to it?
Instead of adding @SupressWarnings to a method, can we add @Deprecated to it?
If I understand correctly, there should be no warning if a deprecated method
calls another deprecated method. And by deprecating the caller we will get
warnings if they are called by more methods and we can evaluate if
Hi Jason
I noticed several "@SuppressWarnings("deprecation")" in some sun.* or com.sun.*
classes and it makes me feel uncomfortable. The usage of this annotation, if I
understand correctly, means we know we should not use it but we have to use it
because we are lazy or there are no better alter
Object cs = new CS(urls[next(state)]);
pdcacheC.computeIfAbsent(cs, x -> "");
}
private int next(ThreadState state) {
return state.rand.nextInt(num);
}
}
--Max
> -Pavel
>
>> On 25 Nov 2014, at 12:02, Wang Weijun wrote:
>>
>> I am ben
I am benchmarking security manager and notice this
protected synchronized InetAddress getHostAddress(URL u) {
if (u.hostAddress != null)
return u.hostAddress;
String host = u.getHost();
if (host == null || host.equals("")) {
return null;
} else {
try {
>
> Michael
>
> On 26/08/14 01:58, Wang Weijun wrote:
>> Hi Michael
>>
>> Please review the code change at
>>
>>http://cr.openjdk.java.net/~weijun/8055901/webrev.00/
>>
>> With this change, the policy tool can generate a fil
Hi Michael
Please review the code change at
http://cr.openjdk.java.net/~weijun/8055901/webrev.00/
With this change, the policy tool can generate a file like
grant {
permission jdk.net.NetworkPermission "setOption.SO_FLOW_SLA";
};
Please confirm the grammar is correct.
BTW, I also add som
There are 2 sun.net.dns.ResolverConfigurationImpl implementations. The cached
searchlist and nameservers in the solaris version are instance fields and those
in windows are static. The cache mechanism in both is guarded by static fields
changed and lastRefresh. Therefore it seems the solaris sea
t;> that this is a cost-effective update if we considering the overall
>> system of Kerberos.
>>
>> Xuelei
>>
>> On 6/24/2014 4:17 PM, Wang Weijun wrote:
>>> Hi All
>>>
>>> Please review the code change at
>>>
>>> http://cr.openjdk.java.net/~weijun/8014870/webrev.00/
>>>
Hi All
Please review the code change at
http://cr.openjdk.java.net/~weijun/8014870/webrev.00/
In Kerberos, when trying to request for a ticket, we tried multiple KDC servers
for multiple times. Before this fix, we connect to a server, wait for 30
seconds (the default kdc_timeout). If there
Ping again.
On Jun 12, 2014, at 14:07, Wang Weijun wrote:
> Hi All
>
> Please review the code change at
>
> http://cr.openjdk.java.net/~weijun/7150092/webrev.00/
>
> The problem is that in NTLM, the server might prompt for a domain name (in
> Type 2 message),
The fix looks fine. You might want to remove the cache-related words from the
comment of the new isSupported method.
--Max
On Mar 25, 2014, at 18:48, Anton Litvinov wrote:
> Hello Chris,
>
> Thank you very much for review of this fix and for addressing the review
> request to the second poss
20 matches
Mail list logo
