headers
Dirk-Willem van Gulik | 1 Aug 2005 11:32
Gravatar

Re: Thinkng something like this for mod_auth_svn


Ok found the problem; turns out that if openssl does not have the
extension hardcoded in its objects.c (from objects.txt in crypto/objects;
compiled by a objects.pl perl scripts) then X509V3_EXT_print() does not do
anything sensible with that string unless the flag
X509V3_EXT_PARSE_UNKNOWN or X509V3_EXT_DUMP_UNKNOWN is passed. (And Martin
his code does then sensibly ignore it).

But once you pass either of these flags it then yields a string which is
not proberly terminated - hence making it possible for a bad cert to
segfault the server. Plus the format in any case not usable for any proper
access control.

So that perhaps means that this OID thing requires the re-use an existing
extension (like id-aca, role, etc) known to the locally installed version
of openssl or add to our code some ability, like a DER format string, to
handle arbitrary string extraction from the extension fields.

Dw.

PS: plus right now it seems that ssl_expr_parse.* and ssl_expr_scan.*
    which are generated from the lex/yax files - are under svn control.

Index: ssl_expr_eval.c
===================================================================
--- ssl_expr_eval.c     (revision 226665)
+++ ssl_expr_eval.c     (working copy)
 <at>  <at>  -229,7 +229,25  <at>  <at> 
     /* Loop over all extensions, extract the desired oids */
     for (j = 0; j < count; j++) {
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joe Orton | 1 Aug 2005 12:41
Picon
Favicon

Re: Thinkng something like this for mod_auth_svn

On Mon, Aug 01, 2005 at 02:32:50AM -0700, Dirk-Willem van Gulik wrote:
> Ok found the problem; turns out that if openssl does not have the
> extension hardcoded in its objects.c (from objects.txt in crypto/objects;
> compiled by a objects.pl perl scripts) then X509V3_EXT_print() does not do
> anything sensible with that string unless the flag
> X509V3_EXT_PARSE_UNKNOWN or X509V3_EXT_DUMP_UNKNOWN is passed. (And Martin
> his code does then sensibly ignore it).
>
> But once you pass either of these flags it then yields a string which is
> not proberly terminated - hence making it possible for a bad cert to
> segfault the server. Plus the format in any case not usable for any proper
> access control.

The fix for the lack of NUL-termination is to use apr_pstrmemdup, that 
part of ssl_ext_lookup() wasn't successfully copy'n'pasted though.

But if OpenSSL doesn't know a printable representation for the 
particular extension you care about then I'd guess the best fix is to 
add such support to OpenSSL not to try and fudge round it in mod_ssl?

joe
Permalink | Reply | 1 comment |
headers
Maxime Petazzoni | 1 Aug 2005 13:03
Gravatar

mod_mbox, thread sort and paging

Hi,

In the last thread about mod_mbox (js speed and mbox_size, July 13th),
we settled on a paged browsing for mod_mbox message list because of the
size of a full message list (>500k for a 2000 messages mbox).

This currently works well with date and author sort because we know
exactly how many messages we are going to display per page
(#define DEFAULT_MSGS_PER_PAGE 100, soon configurable). But the thread
sort brings a problem I was not yet able to fix.

In order to be as consistant as possible, we do not want to break
threads. It's also simpler since displaying a thread is a recursive
call, only returning to the caller function when the full thread message
list has been output.

The problem comes when displaying DEFAULT_THREADS_PER_PAGE (#defined to
40 for the moment) outputs more than DEFAULT_MSGS_PER_AGE : we have one
or more empty pages at the end.

We could, of course, count how many messages a call to
display_msglist_thread() outputs. But we would have to count twice : one
for counting messages without displaying them in order to print the page
switcher, and another time when displaying the messages.

Both pass involve recursive and exhaustive traversal of the thread
container structures.

As I write, a possible solution appears to me : we could add a 'count'
element to the Container datatype which contains the number of messages
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dirk-Willem van Gulik | 1 Aug 2005 13:34
Gravatar

Re: Thinkng something like this for mod_auth_svn


On Mon, 1 Aug 2005, Joe Orton wrote:

> The fix for the lack of NUL-termination is to use apr_pstrmemdup, that

Actually - my guess is that _ext_print in openssl needs some fix as well
as I am not sure if the length is correct either.

> particular extension you care about then I'd guess the best fix is to
> add such support to OpenSSL not to try and fudge round it in mod_ssl?

Agreed - a format string would be the sort of thing one would look for -
or an external 'objects.txt' style file; propably inspired from the snmp
code which does much the same thing.

Dw.
Permalink | Reply | 0 comments |
headers
Dirk-Willem van Gulik | 1 Aug 2005 15:42
Gravatar

Re: Thinkng something like this for mod_auth_svn


David, Martin,

The code below may be of help while thesting the CA code.

It simply extracts any OID listed in the config - and when not
recognized/in the hardcoded set of OpenSSL it will still convert it
provided that it is one of the 4 simple string type s(not 7). Apart from
those 4 we may want t allow a sequence of strings.

I am intentionally -not- setting any of the flags on X509V3_EXT_print() as
otherwise a bogus ASN1 string in a client cert may trigger that segfault.

Ultimately I guess this needs to be farmed out to openssl.

Dw.

Index: ssl_expr_eval.c
===================================================================
--- ssl_expr_eval.c     (revision 226665)
+++ ssl_expr_eval.c     (working copy)
 <at>  <at>  -199,7 +199,6  <at>  <at> 
 }

 #define NUM_OID_ELTS 8 /* start with 8 oid slots, resize when needed */
-
 apr_array_header_t *ssl_extlist_by_oid(request_rec *r, const char *oidstr)
 {
     int count = 0, j;
 <at>  <at>  -229,7 +228,28  <at>  <at>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Maxime Petazzoni | 1 Aug 2005 15:43
Gravatar

Charset conversion

Hi,

I recently implemented MIME structure and header parsing into mod_mbox
(http://blog.bulix.org/index.php/blog/494) and I'm facing a charset
problem : mod_mbox outputs UTF-8, but some of the decoded contents are
not in UTF-8 (for example, a =?iso-8859-1?q?...?= header).

Is there any charset conversion facilities in the APR ? I did not see
anything about charsets in the APR autogenerated documentation (from
doxygen).

The iconv() function can do it, but it's from the UNIX98 standard and I
don't think I can use it in an Apache module (and I don't want to, btw).

Any ideas ? I don't know any other module to look in for this.

Thanks in advance,
- Sam

--

-- 
Maxime Petazzoni (http://www.bulix.org)
 -- gone crazy, back soon. leave message.
Permalink | Reply | 3 comments |
headers
Jeff Trawick | 1 Aug 2005 16:41
Picon

Re: Charset conversion

On 8/1/05, Maxime Petazzoni <maxime.petazzoni <at> bulix.org> wrote:
> Hi,
> 
> I recently implemented MIME structure and header parsing into mod_mbox
> (http://blog.bulix.org/index.php/blog/494) and I'm facing a charset
> problem : mod_mbox outputs UTF-8, but some of the decoded contents are
> not in UTF-8 (for example, a =?iso-8859-1?q?...?= header).
> 
> Is there any charset conversion facilities in the APR ? I did not see
> anything about charsets in the APR autogenerated documentation (from
> doxygen).

apr_xlate in apr-util; mod_charset_lite in httpd source tree is one
user of this; further questions on dev <at> apr mailing list
Permalink | Reply | 2 comments |
headers
Maxime Petazzoni | 1 Aug 2005 17:00
Gravatar

Re: Charset conversion

> apr_xlate in apr-util; mod_charset_lite in httpd source tree is one
> user of this; further questions on dev <at> apr mailing list

Ok, this is not in the autogenerated doc provided by Ian Holsman
(http://docx.webperf.org/group__APR__Util.html). Any pointers to the
relevant documentation (exept the header files if possible) ?

Thank you for answering such a n00b question :)
- Sam

--

-- 
Maxime Petazzoni (http://www.bulix.org)
 -- gone crazy, back soon. leave message.
Permalink | Reply | 1 comment |
headers
Maxime Petazzoni | 1 Aug 2005 17:06
Gravatar

Re: Charset conversion

> (http://docx.webperf.org/group__APR__Util.html). Any pointers to the
> relevant documentation (exept the header files if possible) ?

Ok, forget about that, the doc is filed under APR, not APR-Util. I'll
find out how to use that by myself.

Thread closed.
- Sam

--

-- 
Maxime Petazzoni (http://www.bulix.org)
 -- gone crazy, back soon. leave message.
Permalink | Reply | 0 comments |
headers
Joe Orton | 2 Aug 2005 13:00
Picon
Favicon

Re: svn commit: r220307 - in /httpd/httpd/trunk/modules: metadata/mod_setenvif.c ssl/mod_ssl.c ssl/mod_ssl.h ssl/ssl_expr_eval.c

On Fri, Jul 22, 2005 at 02:24:50PM +0200, Sander Striker wrote:
> Joe Orton wrote:
> >On Fri, Jul 22, 2005 at 12:11:56PM -0000, Martin Kraemer wrote:
> >
> >>Author: martin
> >>Date: Fri Jul 22 05:11:55 2005
> >>New Revision: 220307
> >>
> >>URL: http://svn.apache.org/viewcvs?rev=220307&view=rev
> >>Log:
> >>Allow extraction of the values of SSL certificate extensions into
> >>environment variables, so that their value can be used by any
> >>module that is aware of environment variables, as in:
> >
> >
> >So what is the point in posting patches for review if you don't actually 
> >wait for anyone to review them before committing?
> 
> That would be my fault.  We're here at ApacheCon and when Martin said
> he posted to the list first I asked him why he didn't commit to trunk
> directly, since that is C-T-R.  It's a reasonable smallish patch, with
> little impact on existing functionality; hence the nudge.

C-T-R is a good way to accumulate a codebase full of unfinished changes 
if the R bit is ignored by the committer.  Ping Martin.

http://mail-archives.apache.org/mod_mbox/httpd-dev/200507.mbox/%3c20050722101207.GB17365 <at> redhat.com%3e
http://mail-archives.apache.org/mod_mbox/httpd-dev/200507.mbox/%3c20050722110229.GA20303 <at> redhat.com%3e
http://mail-archives.apache.org/mod_mbox/httpd-dev/200507.mbox/%3c20050722121821.GB19040 <at> redhat.com%3e
(Continue reading)

Permalink | Reply | 14 comments |

Gmane