While I'm not at all worried about the memory leaks from openssl
initialization, I am tired of seeing same old, same old using valgrind:

==21087== 4,672 bytes in 3 blocks are still reachable in loss record  
3 of 4
==21087==    at 0x4805622: realloc (vg_replace_malloc.c:306)
==21087==    by 0xB4A784: (within /lib/libcrypto.so.0.9.8b)
==21087==    by 0xB4AEB6: CRYPTO_realloc (in /lib/libcrypto.so.0.9.8b)
==21087==    by 0xBA5AF6: lh_insert (in /lib/libcrypto.so.0.9.8b)
==21087==    by 0xBA85BD: (within /lib/libcrypto.so.0.9.8b)
==21087==    by 0xBA7D2D: (within /lib/libcrypto.so.0.9.8b)
==21087==    by 0xBE2181: ERR_load_X509V3_strings (in /lib/ 
libcrypto.so.0.9.8b)
==21087==    by 0xBA97C9: ERR_load_crypto_strings (in /lib/ 
libcrypto.so.0.9.8b)
==21087==    by 0x1FA956: SSL_load_error_strings (in /lib/libssl.so. 
0.9.8b)
==21087==    by 0x4B44690: (within /usr/lib/libneon.so.27.0.2)
==21087==    by 0x4B3C12F: ne_sock_init (in /usr/lib/libneon.so.27.0.2)
==21087==    by 0x494B23D: davInit (rpmdav.c:388)
==21087==
==21087==
==21087== 25,944 bytes in 2,084 blocks are still reachable in loss  
record 4 of 4
==21087==    at 0x4805525: malloc (vg_replace_malloc.c:149)
==21087==    by 0xB4A74D: (within /lib/libcrypto.so.0.9.8b)
==21087==    by 0xB4ADCE: CRYPTO_malloc (in /lib/libcrypto.so.0.9.8b)
==21087==    by 0xBA5B5F: lh_insert (in /lib/libcrypto.so.0.9.8b)
==21087==    by 0xBA85BD: (within /lib/libcrypto.so.0.9.8b)
==21087==    by 0xBA7D2D: (within /lib/libcrypto.so.0.9.8b)
==21087==    by 0xBA9575: ERR_load_ERR_strings (in /lib/libcrypto.so. 
0.9.8b)
==21087==    by 0xBA977A: ERR_load_crypto_strings (in /lib/ 
libcrypto.so.0.9.8b)
==21087==    by 0x1FA956: SSL_load_error_strings (in /lib/libssl.so. 
0.9.8b)
==21087==    by 0x4B44690: (within /usr/lib/libneon.so.27.0.2)
==21087==    by 0x4B3C12F: ne_sock_init (in /usr/lib/libneon.so.27.0.2)
==21087==    by 0x494B23D: davInit (rpmdav.c:388)

What's the best way to get rid of these leaks? I understand perfectly
why a neon library cannot eliminate the leaks, see the comments in  
ne_sock_init.

73 de Jeff