[8u] RFR 8201627: Kerberos sequence number issues

[Andrew John Hughes]

On 21/12/2019 05:41, Martin Balao wrote:
> Hello Andrew,
> 
> Thanks for having a look.
> 
> On 12/16/19 3:14 PM, Andrew John Hughes wrote:
>>
>> I think there's a case here for backporting JDK-8154231 or at least
>> bringing over the remaining two methods for GetPropertyAction that
>> weren't part of JDK-8181048.
>>
> 
> What finally introduces a default value argument for
> privilegedGetProperty seems to be 8155775 [1] [2], that depends on
> 8154231 [3] [4]. If you are okay with the approach taken for 8181048
> (cherry picking from 8155775 and 8154231 and including them as part of
> 8181048), I can propose to have privilegedGetProperty with a default
> value argument and privilegedGetProperties as part of the 8u backport of
> 8201627. privilegedGetProperties is not used by 8201627 though.
> 

We can take this minimal approach for 8u242 and do the full backport in
8u252. I'll take a look over the webrev you posted tomorrow.

>>>
>>>  * test/sun/security/krb5/auto/BasicProc.java (several adjustments)
>>
>> What are these "several adjustments"? It looks to me like the
>> refactoring in JDK-8186884 needs backporting first, as this patch seems
>> to drag in some of those changes as well.
>>
> 
> 8186884 is far from applying cleanly to 8u. I've not analyzed all the
> dependencies, but have seen many hook failures.
> 
> In Basic.java, what happens is that jtreg run header has the old way of
> specifying a custom NameService to resolve domains:
> -Dsun.net.spi.nameservice.provider.1=ns,mock instead of
> -Djdk.net.hosts.file=TestHosts. I duplicated the run jtreg header to add
> -Dsun.security.krb5.acceptor.sequence.number.nonmutual=zero parameter.
> The @bug jtreg header hook does not apply cleanly because 8194486 is not
> in 8u.
> 
> In BasicProc.java, the jtreg header hook does not apply cleanly because
> of some patches missing in 8u: 8186884 and 8194486. The other changes
> -probably because of the lack of 8186884 in 8u- are intended to keep the
> semantics. For example, for "client" I added a request to have mutual
> authentication, removed the "Token" variable, sent the wrapped message
> and the message integrity code (MIC). I can continue describing all the
> changes but would be easier to compare file vs file.
> 
> If it helps, no regressions were introduced to the sun/security/krb5
> test category (116 / 116 passes).
> 
> My concern is that all 8155775, 8154231, 8186884 and possible
> 8186884-dependencies are quite big patches not critical for Jan 2020
> CPU. 8201627 is critical though.
> 
> I've tagged 8201627 with jdk8u-critical-request label.
> 

I share the concern about adding 8155775 & 8154231 at this late stage. I
think we should do the full backport in 8u252, but use a minimal one in
8u242 if 8201627 needs to go there.

8186884 should be ok, given it's a test only change, but I'll look at
the backport of that one and see how viable it is.

> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8155775
> [2] - http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/930d3aef37ee#l51.32
> [3] - https://bugs.openjdk.java.net/browse/JDK-8154231
> [4] - http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/50d4d6b772d1#l51.1
> 

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew