Re: svn commit: r1054323 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_ssl.xml docs/manual/upgrading.xml modules/ssl/ssl_engine_config.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_private.h

2011-01-03 Thread Kaspar Brand 
On 02.01.2011 19:35, Stefan Fritsch wrote:
 On Sunday 02 January 2011, Rüdiger Plüm wrote:
 Modified: httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c
 URL:
 http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_u
 til_ssl.c?rev=1054323r1=1054322r2=1054323view=diff
 
 == --- httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c
 (original) +++ httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c Sat
 Jan  1 23:56:24 2011 @@ -344,14 +344,32 @@ BOOL
 SSL_X509_getBC(X509 *cert, int *ca,

  #endif
  }

 +/* convert a NAME_ENTRY to UTF8 string */
 +char *SSL_X509_NAME_ENTRY_to_string(apr_pool_t *p,
 X509_NAME_ENTRY *xsne) +{
 +char *result = NULL;
 +BIO* bio;
 +int len;
 +
 +if ((bio = BIO_new(BIO_s_mem())) == NULL)
 +return NULL;
 +ASN1_STRING_print_ex(bio, X509_NAME_ENTRY_get_data(xsne),
 +
 ASN1_STRFLGS_ESC_CTRL|ASN1_STRFLGS_UTF8_CONVERT); +len =
 BIO_pending(bio);
 +result = apr_palloc(p, len+1);
 +len = BIO_read(bio, result, len);
 +result[len] = NUL;
 +BIO_free(bio);
 +ap_xlate_proto_from_ascii(value, len);

 Shouldn't that be ap_xlate_proto_from_ascii(result, len); instead?
 
 Of course, thanks. Fixed in r1054453.

I would suggest to drop the ap_xlate_proto_from_ascii line completely,
for several reasons: result is now a UTF-8 encoded string (i.e., might
well include non-ASCII characters, differently encoded than ISO-8859-1),
ap_xlate_proto_from_ascii is a NOOP for non-EBCDIC platforms, and third,
on EBCDIC platforms, ap_xlate_proto_from_ascii simply does nothing (it
calls apr_xlate_conv_buffer, which returns APR_ENOTIMPL, even in current
versions of APR-util, IIMN).

Kaspar

Re: svn commit: r1054323 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_ssl.xml docs/manual/upgrading.xml modules/ssl/ssl_engine_config.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_private.h

2011-01-03 Thread Eric Covener 
 on EBCDIC platforms, ap_xlate_proto_from_ascii simply does nothing (it
 calls apr_xlate_conv_buffer, which returns APR_ENOTIMPL, even in current
 versions of APR-util, IIMN).

For EBCDIC you're being mislead by the !APR_HAS_XLATE half of xlate.c
-- it's not a no-op.

Re: svn commit: r1054323 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_ssl.xml docs/manual/upgrading.xml modules/ssl/ssl_engine_config.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_private.h

2011-01-03 Thread Eric Covener 
On Mon, Jan 3, 2011 at 1:21 PM, Eric Covener cove...@gmail.com wrote:
 on EBCDIC platforms, ap_xlate_proto_from_ascii simply does nothing (it
 calls apr_xlate_conv_buffer, which returns APR_ENOTIMPL, even in current
 versions of APR-util, IIMN).

 For EBCDIC you're being mislead by the !APR_HAS_XLATE half of xlate.c
 -- it's not a no-op.

Don't know how my gmail managed to break the threading here, sorry.

Re: svn commit: r1054323 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_ssl.xml docs/manual/upgrading.xml modules/ssl/ssl_engine_config.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_private.h

2011-01-03 Thread Kaspar Brand 
On 03.01.2011 19:21, Eric Covener wrote:
 on EBCDIC platforms, ap_xlate_proto_from_ascii simply does nothing (it
 calls apr_xlate_conv_buffer, which returns APR_ENOTIMPL, even in current
 versions of APR-util, IIMN).
 
 For EBCDIC you're being mislead by the !APR_HAS_XLATE half of xlate.c
 -- it's not a no-op.

Ah, right - my mistake. But even on an EBCDIC platform,
ap_xlate_proto_from_ascii would only make sense if we were converting
pure 8-bit character strings (from ISO-8859-1 to some EBCDC code page),
right?

Kaspar

Re: svn commit: r1054323 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_ssl.xml docs/manual/upgrading.xml modules/ssl/ssl_engine_config.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_private.h

2011-01-03 Thread Eric Covener 
On Mon, Jan 3, 2011 at 1:47 PM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
 On 03.01.2011 19:21, Eric Covener wrote:
 on EBCDIC platforms, ap_xlate_proto_from_ascii simply does nothing (it
 calls apr_xlate_conv_buffer, which returns APR_ENOTIMPL, even in current
 versions of APR-util, IIMN).

 For EBCDIC you're being mislead by the !APR_HAS_XLATE half of xlate.c
 -- it's not a no-op.

 Ah, right - my mistake. But even on an EBCDIC platform,
 ap_xlate_proto_from_ascii would only make sense if we were converting
 pure 8-bit character strings (from ISO-8859-1 to some EBCDC code page),
 right?

AIUI yes as it's meant for the protocol data which is in that known charset.

Re: svn commit: r1054323 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_ssl.xml docs/manual/upgrading.xml modules/ssl/ssl_engine_config.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_private.h

2011-01-03 Thread Stefan Fritsch 
On Monday 03 January 2011, Kaspar Brand wrote:
 On 03.01.2011 19:21, Eric Covener wrote:
  on EBCDIC platforms, ap_xlate_proto_from_ascii simply does
  nothing (it calls apr_xlate_conv_buffer, which returns
  APR_ENOTIMPL, even in current versions of APR-util, IIMN).
  
  For EBCDIC you're being mislead by the !APR_HAS_XLATE half of
  xlate.c -- it's not a no-op.
 
 Ah, right - my mistake. But even on an EBCDIC platform,
 ap_xlate_proto_from_ascii would only make sense if we were
 converting pure 8-bit character strings (from ISO-8859-1 to some
 EBCDC code page), right?

ap_xlate_proto_from_ascii() does the right thing for DN strings that 
contain only ASCII characters. For non-ASCII characters it produces 
broken results, but that would not be a regression. Therefore we 
should leave the ap_xlate_proto_from_ascii() call there. Maybe someone 
familiar with EBCDIC can write an improved conversion function (maybe 
just escape all high-bit characters?). But I don't see that as a 
showstopper.

Re: svn commit: r1054323 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_ssl.xml docs/manual/upgrading.xml modules/ssl/ssl_engine_config.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_private.h

2011-01-03 Thread Kaspar Brand 
On 03.01.2011 22:11, Stefan Fritsch wrote:
 On Monday 03 January 2011, Kaspar Brand wrote:
 Ah, right - my mistake. But even on an EBCDIC platform,
 ap_xlate_proto_from_ascii would only make sense if we were
 converting pure 8-bit character strings (from ISO-8859-1 to some
 EBCDC code page), right?
 
 ap_xlate_proto_from_ascii() does the right thing for DN strings that 
 contain only ASCII characters. For non-ASCII characters it produces 
 broken results, but that would not be a regression. Therefore we 
 should leave the ap_xlate_proto_from_ascii() call there.

Ok, true. For the sake of better readability, could we put that line
into an #if APR_CHARSET_EBCDIC block, to make it obvious that it's a
no-op for non-EBCDIC platforms?

 Maybe someone
 familiar with EBCDIC can write an improved conversion function (maybe 
 just escape all high-bit characters?).

Does APR-util support some kind of (lossy) conversion from UTF-8 to
EBCDIC? If so, server/util_ebcdic.c could be extended accordingly.

Kaspar

Re: svn commit: r1054323 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_ssl.xml docs/manual/upgrading.xml modules/ssl/ssl_engine_config.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_private.h

2011-01-02 Thread Rüdiger Plüm 


On 01/02/2011 12:56 AM, s...@apache.org wrote:
 Author: sf
 Date: Sat Jan  1 23:56:24 2011
 New Revision: 1054323
 
 URL: http://svn.apache.org/viewvc?rev=1054323view=rev
 Log:
 Change the format of the SSL_{CLIENT,SERVER}_{I,S}_DN variables
 to be RFC 2253 compatible, convert non-ASCII characters to UTF8, and 
 escape other special characters with backslashes. The old format can
 still be used with the LegacyDNStringFormat argument to SSLOptions.
 
 Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml
 httpd/httpd/trunk/docs/manual/upgrading.xml
 httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
 httpd/httpd/trunk/modules/ssl/ssl_engine_vars.c
 httpd/httpd/trunk/modules/ssl/ssl_private.h
 httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c
 httpd/httpd/trunk/modules/ssl/ssl_util_ssl.h

 Modified: httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c?rev=1054323r1=1054322r2=1054323view=diff
 ==
 --- httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c (original)
 +++ httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c Sat Jan  1 23:56:24 2011
 @@ -344,14 +344,32 @@ BOOL SSL_X509_getBC(X509 *cert, int *ca,
  #endif
  }
  
 +/* convert a NAME_ENTRY to UTF8 string */
 +char *SSL_X509_NAME_ENTRY_to_string(apr_pool_t *p, X509_NAME_ENTRY *xsne)
 +{
 +char *result = NULL;
 +BIO* bio;
 +int len;
 +
 +if ((bio = BIO_new(BIO_s_mem())) == NULL)
 +return NULL;
 +ASN1_STRING_print_ex(bio, X509_NAME_ENTRY_get_data(xsne),
 + ASN1_STRFLGS_ESC_CTRL|ASN1_STRFLGS_UTF8_CONVERT);
 +len = BIO_pending(bio);
 +result = apr_palloc(p, len+1);
 +len = BIO_read(bio, result, len);
 +result[len] = NUL;
 +BIO_free(bio);
 +ap_xlate_proto_from_ascii(value, len);

Shouldn't that be ap_xlate_proto_from_ascii(result, len); instead?

Regards

Rüdiger

Re: svn commit: r1054323 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_ssl.xml docs/manual/upgrading.xml modules/ssl/ssl_engine_config.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_private.h

2011-01-02 Thread Stefan Fritsch 
On Sunday 02 January 2011, Rüdiger Plüm wrote:
 On 01/02/2011 12:56 AM, s...@apache.org wrote:
  Author: sf
  Date: Sat Jan  1 23:56:24 2011
  New Revision: 1054323
  
  URL: http://svn.apache.org/viewvc?rev=1054323view=rev
  Log:
  Change the format of the SSL_{CLIENT,SERVER}_{I,S}_DN variables
  to be RFC 2253 compatible, convert non-ASCII characters to UTF8,
  and escape other special characters with backslashes. The old
  format can still be used with the LegacyDNStringFormat argument
  to SSLOptions.
  
  Modified:
  httpd/httpd/trunk/CHANGES
  httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml
  httpd/httpd/trunk/docs/manual/upgrading.xml
  httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
  httpd/httpd/trunk/modules/ssl/ssl_engine_vars.c
  httpd/httpd/trunk/modules/ssl/ssl_private.h
  httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c
  httpd/httpd/trunk/modules/ssl/ssl_util_ssl.h
  
  Modified: httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c
  URL:
  http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_u
  til_ssl.c?rev=1054323r1=1054322r2=1054323view=diff
  
  == --- httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c
  (original) +++ httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c Sat
  Jan  1 23:56:24 2011 @@ -344,14 +344,32 @@ BOOL
  SSL_X509_getBC(X509 *cert, int *ca,
  
   #endif
   }
  
  +/* convert a NAME_ENTRY to UTF8 string */
  +char *SSL_X509_NAME_ENTRY_to_string(apr_pool_t *p,
  X509_NAME_ENTRY *xsne) +{
  +char *result = NULL;
  +BIO* bio;
  +int len;
  +
  +if ((bio = BIO_new(BIO_s_mem())) == NULL)
  +return NULL;
  +ASN1_STRING_print_ex(bio, X509_NAME_ENTRY_get_data(xsne),
  +
  ASN1_STRFLGS_ESC_CTRL|ASN1_STRFLGS_UTF8_CONVERT); +len =
  BIO_pending(bio);
  +result = apr_palloc(p, len+1);
  +len = BIO_read(bio, result, len);
  +result[len] = NUL;
  +BIO_free(bio);
  +ap_xlate_proto_from_ascii(value, len);
 
 Shouldn't that be ap_xlate_proto_from_ascii(result, len); instead?

Of course, thanks. Fixed in r1054453.