Re: mod_ssl broken
From: Ben Laurie <ben_at_algroup.co.uk>
Date: 2001-09-09 22:50:28 CEST
Sander Striker wrote:
I've looked into this slightly, and the underlying problem is that
I got stuck at that point, coz it really isn't at all clear where the
Cheers,
Ben.
-- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Return-Path: <dougm@covalent.net> Delivered-To: moderator for dev@subversion.tigris.org Received: (qmail 13645 invoked from network); 9 Sep 2001 21:01:38 -0000 Received: from adsl-216-103-208-11.dsl.snfc21.pacbell.net (HELO mako.covalent.net) (216.103.208.11) by h35.sny.collab.net with SMTP; 9 Sep 2001 21:01:38 -0000 Received: from localhost (dougm@localhost) by mako.covalent.net (8.11.0/8.11.0) with ESMTP id f89L3O929827; Sun, 9 Sep 2001 14:03:24 -0700 X-Authentication-Warning: mako.covalent.net: dougm owned process doing -bs Date: Sun, 9 Sep 2001 14:03:24 -0700 (PDT) From: Doug MacEachern <dougm@covalent.net> To: dev@httpd.apache.org cc: dev@subversion.tigris.org Subject: Re: mod_ssl broken In-Reply-To: <JLEGKKNELMHCJPNMOKHOIENKEIAA.striker@apache.org> Message-ID: <Pine.LNX.4.21.0109091359190.8695-100000@mako.covalent.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 9 Sep 2001, Sander Striker wrote: mod_ssl is working fine here, passes all httpd-test tests (t/TEST -ssl) that includes perdir merging. are you up to date with httpd-2.0 from cvs? > mod_ssl segfaults in ssl_config_perdir_merge: > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1024 (LWP 9130)] > 0x806dd1d in ssl_config_perdir_merge (p=0x814e22c, basev=0x0, > addv=0x8192e4c) at ssl_engine_config.c:269 > 269 cfgMergeArray(aRequirement); > (gdb) bt > #0 0x806dd1d in ssl_config_perdir_merge (p=0x814e22c, basev=0x0, > addv=0x8192e4c) at ssl_engine_config.c:269 i don't think basev should ever be NULL here. can somebody confirm? > #1 0x80a2c15 in ap_merge_per_dir_configs (p=0x814e22c, base=0x8192f34, > new_conf=0x8192c54) at config.c:262 > #2 0x80b7376 in ap_location_walk (r=0x814e25c) at request.c:1236 this is in the area of new directory/location walk optmizations, i have a feeling the bug is there, not mod_ssl. wrowe could probably provide some insight here. Return-Path: <ben@algroup.co.uk> Delivered-To: moderator for dev@subversion.tigris.org Received: (qmail 13717 invoked from network); 9 Sep 2001 21:02:06 -0000 Received: from sockittome.aldigital.co.uk (HELO scuzzy.ben.algroup.co.uk) (194.128.162.252) by h35.sny.collab.net with SMTP; 9 Sep 2001 21:02:06 -0000 Received: from algroup.co.uk (wiese.ben.algroup.co.uk [193.133.15.150]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 1A69E2F55B; Sun, 9 Sep 2001 21:02:05 +0000 (GMT) Message-ID: <3B9BD8CC.F7E86530@algroup.co.uk> Date: Sun, 09 Sep 2001 22:02:04 +0100 From: Ben Laurie <ben@algroup.co.uk> X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: dev@httpd.apache.org Cc: dev@subversion.tigris.org Subject: Re: mod_ssl broken References: <JLEGKKNELMHCJPNMOKHOIENKEIAA.striker@apache.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To be completely accurate, the request is: OPTIONS /svn HTTP/1.1 Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Return-Path: <ben@algroup.co.uk> Delivered-To: moderator for dev@subversion.tigris.org Received: (qmail 14636 invoked from network); 9 Sep 2001 21:06:46 -0000 Received: from sockittome.aldigital.co.uk (HELO scuzzy.ben.algroup.co.uk) (194.128.162.252) by h35.sny.collab.net with SMTP; 9 Sep 2001 21:06:46 -0000 Received: from algroup.co.uk (wiese.ben.algroup.co.uk [193.133.15.150]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id B12DB2F55B; Sun, 9 Sep 2001 21:06:45 +0000 (GMT) Message-ID: <3B9BD9E5.C4218B4C@algroup.co.uk> Date: Sun, 09 Sep 2001 22:06:45 +0100 From: Ben Laurie <ben@algroup.co.uk> X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: dev@httpd.apache.org Cc: dev@subversion.tigris.org Subject: Re: mod_ssl broken References: <Pine.LNX.4.21.0109091359190.8695-100000@mako.covalent.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug MacEachern wrote: > > On Sun, 9 Sep 2001, Sander Striker wrote: > > mod_ssl is working fine here, passes all httpd-test tests (t/TEST -ssl) > that includes perdir merging. > are you up to date with httpd-2.0 from cvs? Yes. > > > mod_ssl segfaults in ssl_config_perdir_merge: > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 1024 (LWP 9130)] > > 0x806dd1d in ssl_config_perdir_merge (p=0x814e22c, basev=0x0, > > addv=0x8192e4c) at ssl_engine_config.c:269 > > 269 cfgMergeArray(aRequirement); > > (gdb) bt > > #0 0x806dd1d in ssl_config_perdir_merge (p=0x814e22c, basev=0x0, > > addv=0x8192e4c) at ssl_engine_config.c:269 > > i don't think basev should ever be NULL here. can somebody confirm? > > > #1 0x80a2c15 in ap_merge_per_dir_configs (p=0x814e22c, base=0x8192f34, > > new_conf=0x8192c54) at config.c:262 > > #2 0x80b7376 in ap_location_walk (r=0x814e25c) at request.c:1236 > > this is in the area of new directory/location walk optmizations, i have a > feeling the bug is there, not mod_ssl. wrowe could probably provide some > insight here. I am absolutely sure it is there (see my posts). Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Return-Path: <icecream@bayarea.net> Delivered-To: moderator for dev@subversion.tigris.org Received: (qmail 8236 invoked from network); 10 Sep 2001 19:39:38 -0000 Received: from shell4.bayarea.net (209.128.82.1) by h35.sny.collab.net with SMTP; 10 Sep 2001 19:39:38 -0000 Received: from modrick (209-128-79-218.bayarea.net [209.128.79.218]) by shell4.bayarea.net (8.9.3/8.9.3) with SMTP id MAA31430 for <dev@subversion.tigris.org>; Mon, 10 Sep 2001 12:39:37 -0700 (envelope-from icecream@bayarea.net) Date: Mon, 10 Sep 2001 12:42:20 -0700 From: Wonko The Sane <icecream@bayarea.net> To: dev@subversion.tigris.org Subject: Re: It is time to upgrade to autoconf 2.50 and libtool 1.4. Message-Id: <20010910124220.2ded486c.icecream@bayarea.net> In-Reply-To: <86pu8yn99b.fsf@kepler.ch.collab.net> References: <20010910121731.4a5899e6.supermo@bayarea.net> <86pu8yn99b.fsf@kepler.ch.collab.net> Organization: H2 X-Mailer: Sylpheed version 0.4.99cvs6 (GTK+ 1.2.7; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On 10 Sep 2001 14:20:00 -0500 Ben Collins-Sussman <sussman@collab.net> wrote: > Mo DeJong <supermo@bayarea.net> writes: > > > Now would be the perfect time to upgrade subversion to the > > most recent stable releases of autoconf and libtool. We were > > waiting until an issue in apr had been resolved, and the > > good news is that it is no longer a problem since apr > > no longer tries to build in the shmem/unix/mm dir. > > I noticed there were some autoconf/libtool related > > complaints recently on the list, this patch should > > make many of them go away. > > I thought Subversion was waiting for APR to move to the latest > autoconf/libtool; are you saying that APR now works with autoconf > 2.50 and libtool 1.4? I just had heard any news of this on the APR > dev list. On the other hand, I wasn't following this svn thread > closely either. :-) We were just waiting until APR worked with the autoconf 2.50 and libtool 1.4 releases. APR will continue to work with the older autoconf/libtool but subversion needs the libtool fixes (badly). After this patch is added, configuring subversion will require the new versions of these tools, which is why we need our own buildconf.sh script. > Can we really just start using the latest tools, and APR, db, and neon > will all just work? Yeah. The db package moved to the new autoconf in the 3.3.11 release. Neon should be upgraded, but that is a separate issue since we pull down an already configured tar ball for neon. Things should just work (I know, you heard that one before). I just did a build under Linux and it worked just fine. > > Also, could someone make sure the new buildcheck.sh > > and the existing autogen.sh have the execute bit set? > > Execute bit? What's that? :-) > > We're self-hosting now. We can't have that sort of functionality > until we get properties coming down to our working copies over DAV. > We're working on it. Congrats! I did my first `svn checkout` today. It felt good, real good. Mo Return-Path: <dale@grim.ws> Delivered-To: moderator for dev@subversion.tigris.org Received: (qmail 21464 invoked from network); 12 Sep 2001 19:04:35 -0000 Received: from unknown (HELO xserver.grim.ws) (209.185.21.52) by h35.sny.collab.net with SMTP; 12 Sep 2001 19:04:35 -0000 Received: by xserver.grim.ws (Postfix, from userid 1000) id 65538B8C6; Wed, 12 Sep 2001 19:03:14 +0000 (GMT) Date: Wed, 12 Sep 2001 19:03:14 +0000 From: Dale Thatcher <subversion@dalethatcher.com> To: dev@subversion.tigris.org Subject: Patch for http proxy support Message-ID: <20010912190314.A29587@grim.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hi, The following is a patch for all those stranded behind http proxies. It allows users to set their http_proxy environment variable in the same way as a few other programs e.g. dselect and wget. export http_proxy=http://username:password@proxyhost:proxyport/ It's probably not suitable to go in as is. In fact I'm not sure if most people will like passing in the settings from the environment. But it allows me access while at work which is much better than CVS. thanks, - Dale Thatcher 2001-09-12 Dale Thatcher <subversion@dalethatcher.com> ra_dav.h Added new fields to svn_ra_session_t to store the proxy uri, username and password. session.c Added two new routines proxy_auth_authenticate, init_http_proxy and modified svn_ra_get_authenticator to call out to the neon http proxy support. User can now set the http_proxy environment variable to use a proxy. Index: ./subversion/libsvn_ra_dav/ra_dav.h =================================================================== --- ./subversion/libsvn_ra_dav/SVN/text-base/ra_dav.h Wed Sep 12 18:45:57 2001 +++ ./subversion/libsvn_ra_dav/ra_dav.h Wed Sep 12 18:45:57 2001 @@ -42,6 +42,10 @@ const char *username; const char *password; + struct uri proxyuri; + char *proxyusername; + char *proxypassword; + ne_session *sess; /* HTTP session to server */ ne_session *sess2; Index: ./subversion/libsvn_ra_dav/session.c =================================================================== --- ./subversion/libsvn_ra_dav/SVN/text-base/session.c Wed Sep 12 18:45:58 2001 +++ ./subversion/libsvn_ra_dav/session.c Wed Sep 12 18:51:27 2001 @@ -84,6 +84,31 @@ return 0; } +static int request_proxy_auth (void *userdata, const char *realm, + char **proxyusername, char **proxypassword) +{ + svn_ra_session_t *ras = userdata; + apr_size_t l; + + l = strlen(ras->proxyusername) + 1; + *proxyusername = malloc(l); + memcpy(*proxyusername, ras->proxyusername, l); + + if (ras->proxypassword == NULL) + { + *proxypassword = malloc(1); + **proxypassword = '\0'; + } + else + { + l = strlen(ras->proxypassword) + 1; + *proxypassword = malloc(l); + memcpy(*proxypassword, ras->proxypassword, l); + } + + return 0; +} + static svn_error_t * auth_authenticate (void **session_baton, void *auth_baton) { svn_ra_session_t *ras = auth_baton; @@ -108,6 +133,80 @@ auth_authenticate }; +static svn_error_t * proxy_auth_authenticate (void **session_baton, void *auth_baton, + char *authinfo) +{ + char *c; + char *usernameend = NULL; + apr_size_t l; + svn_ra_session_t *ras = auth_baton; + + /* parse out username and password */ + ras->proxyusername = NULL; + + for (c = authinfo; *c != '\0'; c++) + { + if (usernameend == NULL && *c == ':') + { + usernameend = c; + } + } + + if (usernameend == NULL) + { + usernameend = c; + } + + l = usernameend - authinfo; + ras->proxyusername = apr_pcalloc(ras->pool, l + 1); + memcpy(ras->proxyusername, authinfo, l); + *(ras->proxyusername + l) = '\0'; + + if (usernameend != c) + { + l = (c - usernameend) - 1; + ras->proxypassword = apr_pcalloc(ras->pool, l + 1); + memcpy(ras->proxypassword, usernameend + 1, l); + *(ras->proxypassword + l) = '\0'; + } + + ne_set_proxy_auth(ras->sess, request_proxy_auth, ras); + ne_set_proxy_auth(ras->sess2, request_proxy_auth, ras); + + *session_baton = ras; + + return SVN_NO_ERROR; +} + +static svn_error_t * init_http_proxy(void **session_baton, void *baton) +{ + svn_ra_session_t *ras = baton; + struct uri proxyuri = ras->proxyuri; + + if (ne_session_proxy(ras->sess, proxyuri.host, proxyuri.port) || + ne_session_proxy(ras->sess2, proxyuri.host, proxyuri.port)) + { + return svn_error_create(SVN_ERR_RA_ILLEGAL_URL, 0, NULL, ras->pool, + "illegal URL for proxy"); + } + + if (proxyuri.authinfo != NULL) + { + svn_error_t *err; + + err = proxy_auth_authenticate((void **)&ras, ras, proxyuri.authinfo); + if (err != SVN_NO_ERROR) + { + return err; + } + } + + *session_baton = ras; + + return SVN_NO_ERROR; +} + + /* ### need an ne_session_dup to avoid the second gethostbyname * call and make this halfway sane. */ @@ -118,6 +217,7 @@ apr_pool_t *pool) { const char *repository = repos_URL->data; + const char *httpproxy = getenv("http_proxy"); apr_size_t len; ne_session *sess, *sess2; struct uri uri = { 0 }; @@ -162,6 +262,28 @@ ne_set_useragent(sess, "SVN/" SVN_VERSION); ne_set_useragent(sess2, "SVN/" SVN_VERSION); + ras = apr_pcalloc(pool, sizeof(*ras)); + ras->pool = pool; + ras->root = uri; + ras->sess = sess; + ras->sess2 = sess2; + + /* set the proxy up if required */ + if (httpproxy != NULL) + { + struct uri proxyuri; + + if (uri_parse(httpproxy, &proxyuri, NULL)) + { + return svn_error_create(SVN_ERR_RA_ILLEGAL_URL, 0, NULL, ras->pool, + "illegal URL for http proxy"); + } + + ras->proxyuri = proxyuri; + + init_http_proxy((void **)&ras, ras); + } + /* we want to know if the repository is actually somewhere else */ /* ### not yet: http_redirect_register(sess, ... ); */ @@ -203,12 +325,6 @@ len = strlen(uri.path); if (len > 1 && uri.path[len - 1] == '/') uri.path[len - 1] = '\0'; - - ras = apr_pcalloc(pool, sizeof(*ras)); - ras->pool = pool; - ras->root = uri; - ras->sess = sess; - ras->sess2 = sess2; if (method == SVN_RA_AUTH_USERNAME) *authenticator = &username_authenticator; Return-Path: <psmith@BayNetworks.COM> Delivered-To: moderator for dev@subversion.tigris.org Received: (qmail 8175 invoked from network); 13 Sep 2001 14:47:29 -0000 Received: from ns2.baynetworks.com (HELO southpass.baynetworks.com) (134.177.3.16) by h35.sny.collab.net with SMTP; 13 Sep 2001 14:47:29 -0000 Received: from mailhost.BayNetworks.COM (ns1.baynetworks.com [134.177.1.107]) by southpass.baynetworks.com (8.9.1/8.9.1) with ESMTP id HAA27843 for <dev@subversion.tigris.org>; Thu, 13 Sep 2001 07:36:20 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id HAA18611 for <dev@subversion.tigris.org>; Thu, 13 Sep 2001 07:45:10 -0700 (PDT) Received: from lemming.engeast.baynetworks.com (lemming [192.32.150.127]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id KAA28528; Thu, 13 Sep 2001 10:47:20 -0400 for <dev@subversion.tigris.org> Received: from psmith by lemming.engeast.baynetworks.com with local (Exim 3.32 #1 (Debian)) id 15hXlo-0002Rr-00; Thu, 13 Sep 2001 10:47:12 -0400 To: Mo DeJong <supermo@bayarea.net> Cc: subversion <dev@subversion.tigris.org> Subject: Re: Patch to add a --verbose option. References: <20010913015103.3efc0837.supermo@bayarea.net> From: "Paul D. Smith" <pausmith@nortelnetworks.com> In-Reply-To: <20010913015103.3efc0837.supermo@bayarea.net> Reply-To: pausmith@nortelnetworks.com Date: 13 Sep 2001 10:47:04 -0400 Message-ID: <p5adzz2lnb.fsf@lemming.engeast.baynetworks.com> Lines: 29 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: "Paul D. Smith" <pausmith@nortelnetworks.com> %% Mo DeJong <supermo@bayarea.net> writes: md> After poking around in the and testing out the apr_getopt_long md> function, I have come to the conclusion that it is not currently md> possible to implement the --verbose option as described in the md> clients/cmdline/README file. md> -V --verbose [ KEY ] [quiet|progress|verbose|trace] I think this might be a typo. The GNU standards state that arguments given to long options use "=", so it should be: > -V --verbose[=KEY] [quiet|progress|verbose|trace] As an example, see the next line: md> -q --quiet alias for --verbose=quiet ^^^^^^^^^^^^^^^ I do something like this in GNU make and it works fine, FWIW. -- ------------------------------------------------------------------------------- Paul D. Smith <pausmith@nortelnetworks.com> HASMAT--HA Software Mthds & Tools "Please remain calm...I may be mad, but I am a professional." --Mad Scientist ------------------------------------------------------------------------------- These are my opinions---Nortel Networks takes no responsibility for them. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org For additional commands, e-mail: dev-help@subversion.tigris.orgReceived on Sat Oct 21 14:36:41 2006 |
This is an archived mail posted to the Subversion Dev mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.