On Wed, 20 Jan 2021 15:08:56 GMT, Aleksei Efimov <aefi...@openjdk.org> wrote:
>> That look reasonable to me. But what would happen if at some point after
>> performing some LDAP operations, you called StartTLSResponse::close and then
>> after some more time you tried to again create a StartTLSRequest on the same
>> context? Would that work - or would you be using a possibly obsolete channel
>> binding obtained from the first upgrade?
>
> The change looks valid to me too.
> I believe Daniel question could be illustrated with the following change to
> `CBwithTLS` reproducer attached to the bug report:
> --- CBwithTLS_Original.java 2021-01-20 14:56:09.620844903 +0000
> +++ CBwithTLS.java 2021-01-20 15:01:47.253982227 +0000
> @@ -45,7 +45,7 @@
> System.out.println(ctxt.getAttributes("", new
> String[]{"defaultNamingContext"}).get("defaultNamingContext").get());
>
> // Switch to TLS
> -
> + for (int i=0; i<2; i++) {
> StartTlsResponse tls = (StartTlsResponse) ctxt.extendedOperation(new
> StartTlsRequest());
> tls.negotiate();
>
> @@ -64,6 +64,9 @@
> lc.login();
>
> Subject.doAs(lc.getSubject(), (PrivilegedAction<Void>)
> CBwithTLS::run);
> + lc.logout();
> + tls.close();
> + }
> }
>
> private static Void run() {
New ChannelBinding Data will be recreated for every TLS connection and provided
to SASL Client in the new environment properties set (cloned from the
original).
LdapSasl.java lines 133 - 136:
TlsChannelBinding tlsCB =
TlsChannelBinding.create(cert);
envProps = (Hashtable<String, Object>) env.clone();
envProps.put(TlsChannelBinding.CHANNEL_BINDING,
tlsCB.getData());
-------------
PR: https://git.openjdk.java.net/jdk/pull/2085
