UTF-8 strings through ap_log_cerror()?

[Sander Temme <sa...@temme.net>]

Folks, 

Referring to this exchange: 

http://www.mail-archive.com/openssl-users@openssl.org/msg60934.html

the culprit calling X509_NAME_oneline() is obviously us, around ssl_engine_kernel.c: 1318 in 2.2.x-head.  While this code has moved to ssl_engine_log.c in trunk, we're still calling the deprecated function.  

According to dr. Stephen, the correct function to call is X509_NAME_print_ex(), but that writes to a BIO.  Could a string be made of a BIO?  And if one were, would ap_log_cerror() be able to print it in all its UTF-8-y glory? 

S.

-- 
sander@temme.net              http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF

Re: UTF-8 strings through ap_log_cerror()?

[Kaspar Brand <ht...@velox.ch>]

On 28.04.2010 04:29, Sander Temme wrote:
> According to dr. Stephen, the correct function to call is
> X509_NAME_print_ex(), but that writes to a BIO.  Could a string be
> made of a BIO?  And if one were, would ap_log_cerror() be able to
> print it in all its UTF-8-y glory?

I'm not sure if it's considered the "canonical" way, but you can use a
memory BIO (BIO_s_mem) for this, and then retrieve the string through
BIO_get_mem_data().

AFAICT, ap_log_cerror would again escape those UTF-8 sequences, however
(T_ESCAPE_LOGITEM is set for all characters > 127, see
server/gen_test_char.c).

Moving away from X509_NAME_oneline() seems like a good idea to me,
generally speaking - X509_NAME_print_ex gives you much better control
over the output format (XN_FLAG_RFC2253 would probably be a reasonable
default choice).

Kaspar