Is the "HASH" algorithm a new name? I'm not sure why introduce this
none-standard name.
39 // The hash algorithm can be "HASH" or "SHA256".
What if the algorithm is not one of the two? Why not use the standard
names? Do you want to support SHA3?
As the DEFAULT_HASH_ALG system property is customizable, the value may
be not valid. Therefore, the AssertionError may be too strong to use in
line 310 of KrbApReq.java, and the message can have more information.
Otherwise, looks fine to me.
Xuelei
On 10/25/2016 12:18 PM, Wang Weijun wrote:
http://cr.openjdk.java.net/~weijun/8168518/webrev.00/
Please read https://bugs.openjdk.java.net/browse/JDK-8168518 for the reason.
This code change includes:
1. Add a hashAlg field in AuthTimeWithHash.java.
2. Add AuthTimeWithHash.DEFAULT_HASH_ALG so we can change it later.
3. The fix of the bug is inside DflCache.java:
@@ -300,7 +302,7 @@
if (time.equals(a)) {
// Exact match, must be a replay
throw new KrbApErrException(Krb5.KRB_AP_ERR_REPEAT);
- } else if (time.isSameIgnoresHash(a)) {
+ } else if (time.sameTimeDiffHash((AuthTimeWithHash)a)) {
// Two different authenticators in the same second.
// Remember it
seeNewButNotSame = true;
When a AuthTimeWithHash is seen with a different hash, we believe it's a new
one. Before this fix, we simply compare the HASH string. Now that the algorithm
can be different, we only treat it a new one if the algorithm is the same and
the hash value is different.
This code change has not tried to understand what a different hashAlg means and
try to re-calculate with it. It is just treated as unknown.
Tests updated. ReplayCacheTestProc.java enhanced so it can be called with some
special system properties to test interop between a non-system-default native
library or even between 2 different native libraries.
Thanks
Max
