The GSS and SASL changes look fine to me. Two small questions:
1. If the change in java.security.jgss/share/classes/module-info.java is unavoidable, can we create a sub-package for this single class so that we only need to export it? Or, do you think we can define the sub-class inside GssKrb5Client and directly check its class name in InitialToken? This is a little ugly so you're free to ignore it. 2. Is GSSContextImpl::setChannelBinding really necessary? I don't know if there are people using null to erase a CB set earlier. Thanks, Max > On Jul 3, 2020, at 2:33 AM, Sean Mullan <sean.mul...@oracle.com> wrote: > > On 6/24/20 2:56 PM, Daniel Fuchs wrote: >> The JNDI/LDAP part looks mostly good. You will need someone >> from the security libs to review the security lib part of the >> changes. > > I have previously reviewed it but I would like to give it another once over. > Max should also review the final version as he is the expert in JGSS. > > Given we are around US holidays/vacation, expect some delay. > > I suppose this is a bit of a grey area, but given the scope and the > introduction of new properties and initial support for TLS channel binding, > it seems more like an Enhancement than a Bug to me. That would kind of rule > it out for JDK 15, but I suspect that what is more important is backporting > this to prior releases, and that can be figured out later. So, JDK 16 as an > initial target seems ok to me. > > Thanks, > Sean
