[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Linking Clients::which Crypto API ? (SOLVED)



Hello All,

if any of you are interested how to solve the problem with the current
version of the API, here's the solution:

1. Define the following in your code

	typedef struct tls_impl {
	  const char *ti_name;
	} tls_impl;

	extern tls_impl ldap_int_tls_impl;

2. Now check the ti_name to discover which crypto lib has been linked:

  if(strncmp(ldap_int_tls_impl.ti_name, "MozNSS", 6) == 0)
  {
    // NSS
  }
  else if (strncmp(ldap_int_tls_impl.ti_name, "GnuTLS", 6) == 0)
  {
    // GnuTLS
  }
  else if (strncmp(ldap_int_tls_impl.ti_name, "OpenSSL", 7) == 0)
  {
    // OpenSSL
  }
  else
  {
    // Unknown
  }

I hope this will help other people in building more portable binaries... :D

Cheers,
Max


On 06/10/2011 01:37 AM, Massimiliano Pala wrote:
Hi all,

I have a little problem. I am implementing an application that uses the
OpenLDAP libraries. Until not too much time ago, linking with OpenSSL was
sufficiently safe (on almost every Linux distros) and providing my own
verification function through the SSL_CTX (by using the ldap_set_option(m_ldap,
LDAP_OPT_SERVER_CERTIFICATE, _my_verify)) was easy.

Now, Linux distros started to use GnuTLS, NSS, and OpenSSL as the crypto
API.

My question is: how do I develop an application that when deployed on different
systems might need to use functions and data structures from different crypto-api
(e.g., when I distribute the binaries of my app) ?

How can I retrieve that info *at runtime* (I'd like my binaries to be compatible) ?

At least, is there a function that allows me to know which crypto APIs are
expected by libldap_r (so that I don't pass in the wrong data structure
since it is a (void *)) ? Or at least, is there a way to set/get options so that
I would know which API is in use ?

Thanks,



--

http://member.acm.org/~openca/

Massimiliano Pala, Ph.D.
Director, OpenCA Labs
Professor, NYU Poly

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature