<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@A, and then fallback to
krbtgt/D@A, krbtgt/C@A and krbtgt/B@A. In fact, since the capath is
already there, krbtgt/B@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@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@K1, krbtgt/K3@K2,
krbtgt/K4@K3, krbtgt/K5@K4 and finally get service ticket to
host/host.k5@K5. Now Java can do the same with the same krb5.conf.
Thanks
Max
