Code review request: 8012615: Realm.getRealmsList returns realms list in wrong

[Valerie (Yu-Ching) Peng]

<Config.java>
1. Line 255, "returns if keys exists" should be "returns true if key 
exists".
2. Line 257, "@see get" should be "@see get0"?
3. You may want to add the following to the public getAll(String... 
keys) method.

@throws IllegalArgumentException ...

<CredentialsUtil.java> looks fine

Before I looked at Realm.java, I looked at the test first to understand 
the expected realm list result.

Well, judging from the test, I feel the parsing of these CA path 
settings are too relaxed.
You are allowing all sorts of short cuts and user errors. When has 
capaths been implemented?

I wonder what happens when MIT implementation run into these invalid 
capath settings.
Is their implementation also interpret them like what you have here?

I think your new comment on line 71 is more confusing.
Can you just say "D2=D1 is the same as D2=."?

What happens for the infinite loop case, i.e. G?
What should (G1, G2) returns? G1 G3?
Thanks,
Valerie

On 07/29/13 02:11, Weijun Wang wrote:
> Hi Valerie
>
> Please review the capaths code change at
>
>   http://cr.openjdk.java.net/~weijun/8012615/webrev.01/
>
> It includes:
>
> Config.java
> ===========
>
> Add method to check if a sub-stanza exists.
>
> Realm.java
> ==========
>
> Rewrite reading cross-realm path for both [capaths] and hierarchy. The 
> [capaths] part implements the chaining process.
>
> CredentialsUtils.java
> =====================
>
> When reading cross-realm TGT for a path A->B->C->D->SERVERREALM, the 
> current impl first gets krbtgt/SERVERREALM at A, and then fallback to 
> krbtgt/D at A, krbtgt/C at A and krbtgt/B at A. In fact, since the capath is 
> already there, krbtgt/B at A should be the first to check. I don't know 
> about the history of this code and dare not change much. But I at 
> least reverse the order of the fallback (what the code calls inner 
> loop) to try krbtgt/B at A first.
>
> Tried on a local setup of 5 MIT KDC realms configured with a 
> one-direction cross-auth from K1 to K5. The MIT kvno command starts 
> with kinit in K1 and goes thru krbtgt/K2 at K1, krbtgt/K3 at K2, 
> krbtgt/K4 at K3, krbtgt/K5 at K4 and finally get service ticket to 
> host/host.k5 at K5. Now Java can do the same with the same krb5.conf.
>
> Thanks
> Max