Re: proposal, library error codes for TLS failures

[Jan Vcelak <jvcelak@redhat.com>]

Hello,

> > I already tried something. I added LDAP_TLS_INITIALIZATION_ERROR
> > (-19) and LDAP_TLS_NEGOTIATION_ERROR (-20) API error codes and
> > slightly modified the TLS code in OpenLDAP to propagate the errors.
> > These two new error codes are sufficient for SSSD.
> 
>  This suggestion makes me itchy in so many ways.

Why?

>  About the -Z option (attempted TLS without verification):

Actually this is not about -Z behavior. I just mentioned in the mail,
that it would be great if the library provided more information
about the type of the failure.

>  About changing result codes, assuming you still want that:
> 
>  I don't know TLS programming.  Can you get the info you want from
>  ldap_get_option LDAP_OPT_X_TLS_CTX or LDAP_OPT_X_TLS_SSL_CTX?  If
>  not,
>  maybe libldap could save some extra TLS info for the client.

No, you cannot. Because both structures are implementation specific.
And we have OpenSSL, GnuTLS and Mozilla NSS supported by OpenLDAP.
And the manual pages say: 'Applications generally should not use
this option.'

>  I'd like to see API error codes improved.  My favorite is to split
>  LDAP_SERVER_DOWN in at least "could not connect" and "connection
>  lost".

I belive this already works. ldap_get_option with LDAP_OPT_RESULT_CODE
will return LDAP_TIMEOUT.

>  However, we need to be reluctant to change the result code for a
>  given
>  situation.  Changes can break existing code which cares for that
>  situation and handles the current result code.  Such changes belong
>  in
>  the switch to OpenLDAP 2.5 or 3.0.

Yes, it might break some existing applications. Therefore I'm asking
for upstream point of view. But I would like to have a solution for
this in 2.4.

>  For 2.4 I suggest ldap_set_option(ld, LDAP_CODE_POLICY,
>  &policy_version)
>  The LDAP_CODE_POLICY approach needs a general brainstorm about
>  result
>  codes, so we don't end up with too many different policies to
>  support.

I do not like this approach. API versioning might complicate it
too much. And we will get stuck with another ldap_set_option flag.

Jan