mod_ssl fix for PR# 27106
hi all, apacheweek has announced a vulnerability: http://www.apacheweek.com/features/security-20 the bugzilla problem report indicates this diff fixes the problem: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_engine_io.c? r1=1.117r2=1.118 recent email on the dev list includes -two- diffs under the PR report: * mod_ssl: Fix nasty memory leak for each plain-HTTP-on-SSL-port request. PR: 27106 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_engine_io.c? r1=1.117r2=1.118 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_engine_io.c? r1=1.120r2=1.121 can someone please tell me if i need both of the patches or only one? if i need both patches, is the bugzilla report wrong? my source code base is the 2.0.48 release. cheers, andy
RE: mod_ssl fix for PR# 27106
thanks, andy -Original Message- From: Joe Orton [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 09, 2004 6:14 AM To: Andy Cutright Cc: [EMAIL PROTECTED] Subject: Re: mod_ssl fix for PR# 27106 On Mon, Mar 08, 2004 at 02:47:10PM -0800, Andy Cutright wrote: apacheweek has announced a vulnerability: http://www.apacheweek.com/features/security-20 the bugzilla problem report indicates this diff fixes the problem: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_en gine_io.c? r1=1.117r2=1.118 recent email on the dev list includes -two- diffs under the PR report: ... can someone please tell me if i need both of the patches or only one? if i need both patches, is the bugzilla report wrong? my source code base is the 2.0.48 release. Use both the patches or just fetch the backported patch which includes both changes: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_en gine_io.c?r1=1.100.2.11r2=1.100.2.12 joe
mixing c c++ on HP-UX
hi all, there was some discussion on this list about HP-UX and c++ modules. we had a mixture like this running with 2.0.43. we've recently upgraded to 2.0.44, and we're now experiencing problems at load time. i'm wondering if anyone is running 2.0.44 on HP-UX with c++ modules successfully, cheers, andy
Re: mixing c c++ on HP-UX
hi bill, thanks for your help. that doesn't seem to be the root cause. we've been loading our modules without BIND_NOSTART for a while now on HP-UX. the program is dumping core in apr_pools.c:1976 with a SIGSEGV. i'm gonna start digging deeper, cheers, andy William A. Rowe, Jr. wrote: Andy, there were new fixes in 2.0.45 that should address this. See... http://cvs.apache.org/viewcvs.cgi/apr/dso/unix/dso.c Bill At 04:57 PM 3/31/2003, Andy Cutright wrote: hi all, there was some discussion on this list about HP-UX and c++ modules. we had a mixture like this running with 2.0.43. we've recently upgraded to 2.0.44, and we're now experiencing problems at load time. i'm wondering if anyone is running 2.0.44 on HP-UX with c++ modules successfully, cheers, andy
Re: Mod_ssl for Apache 2.0.39 on W2K and using Bison for apache compiling
you can hack this stuff out, i believe. try looking through .mak file that's giving you problems get rid of the comand being issued for that target, or get rid of the target. i _think_ you'll find that the bison stuff is trying ultimately to create an already existing header file. caveat emptor, cheers, andy EMRE KUNT (Ebi Bsk. - Sistem Prog) wrote: Hello, I am using apache2.0.39 on Win2000 and want to install it with mod_ssl.so At the compilation step, the errors below appeared. Question 1: Do you know what the problem is? Question 2: Do you know how to use Bison on W2000 in MS Visual C 6 to compile apache? (which .h and .l files are to be used for Bison) Thanks and best regards, Emre Kunt C:\httpd-2.0.39\modules\sslNMAKE -f mod_ssl.mak CFG="mod_ssl - Win32 Debug" RE CURSE=0 .\Debug\mod_ssl.so Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. tempfile.bat bison: /tmp/b.act.a01820: No such file or directory The system cannot find the file specified. Could Not Find C:\httpd-2.0.39\modules\ssl\y.tab.c The system cannot find the file specified. Could Not Find C:\httpd-2.0.39\modules\ssl\y.tab.h NMAKE : fatal error U1077: 'tempfile.bat' : return code '0x1' Stop.
ltconfig, libtool, 2.0.39 vs. 2.0.43
hi all, i've been wrestling with linking running 2.0.43 on AIX 5.1 for a couple of days. we have 2.0.39 running fine. i've pulled down both the unix source code .tar.Z the windows source code distribution. i see something i'm not sure about in httpd-2.0.43/srclib/apr/build/ltconfig: VERSION=1.3.4-freebsd-ports this is odd to me, since my _generated_ httpd-2.0.39/srclib/apr/build/libtool for 2.0.39 has a version 1.4.2. also, i don't see a httpd-2.0.39/srclib/apr/build/ltconfig in the source tree we have. i'll try to re-pull the .39 sources to verify it's not my mistake. this affects how shared libraries are built, and httpd is dumping core when attempting to load the .so modules when they're built using the generated libtool/shlibtool system. these .sos load fine if i build/ link them 'by hand'. i searched the mail archives but didn't see anything specific about this issue. cheers, andy
Re: ltconfig, libtool, 2.0.39 vs. 2.0.43
hi all, more information. all the ltmain.sh files seem to have regressed from 2.0.39 to 2.0.43. is this on purpose? the first set of greps is from 2.0.43, and the second from 2.0.39 to the best of my knowledge. /httpd-2.0.43 foreach FILE (`find . -name ltmain.sh`) ? cat $FILE |grep VERSION ? end VERSION=1.3.4-freebsd-ports if test $LTCONFIG_VERSION != $VERSION; then echo $modename: ltconfig version \`$LTCONFIG_VERSION' does not match $PROGRAM version \`$VERSION' 12 echo $PROGRAM (GNU $PACKAGE) $VERSION$TIMESTAMP /* Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP */ # Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP # Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP VERSION=1.4 echo $PROGRAM (GNU $PACKAGE) $VERSION$TIMESTAMP /* Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP */ # Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP # Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP VERSION=1.3.4-freebsd-ports if test $LTCONFIG_VERSION != $VERSION; then echo $modename: ltconfig version \`$LTCONFIG_VERSION' does not match $PROGRAM version \`$VERSION' 12 echo $PROGRAM (GNU $PACKAGE) $VERSION$TIMESTAMP /* Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP */ # Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP # Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP /src/srclib foreach FILE (`find . -name ltmain.sh`) ? cat $FILE | grep VERSION ? end VERSION=1.4.2 echo $PROGRAM (GNU $PACKAGE) $VERSION$TIMESTAMP /* Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP */ # Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP # Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP VERSION=1.4.2 echo $PROGRAM (GNU $PACKAGE) $VERSION$TIMESTAMP /* Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP */ # Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP # Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP VERSION=1.4 echo $PROGRAM (GNU $PACKAGE) $VERSION$TIMESTAMP /* Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP */ # Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP # Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP
Re: compatibility with C++ modules
hi, so could you possibly speak those unspeakable hacks you've made to apache to run c++ modules on hp? we're trying to get a c++ module linked into 2.0.39. any help would be appreciated. we can take this particular aspect of the discussion out of this forum, if you'd prefer, cheers andy Jeff Trawick wrote: At about the same time recently that I was doing horrible, uncommittable hacks to the build to get Apache 2.0 to support C++ modules on HP-UX, somebody wrote a PR against Apache 1.3 pointing out the same issue I encountered: If httpd is to properly support C++ modules, it may need to be linked with something other than the C compiler front-end, depending on the compiler and the platform. -- buy the buddha a beer tell him to move on to the next town -- Borland -- Enabling a new digital world where our customers have the freedom of choice to develop, deploy, and integrate applications across the enterprise and the Internet. http://www.borland.com This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof.
compile time issue
hi all, my apologies if this is not the appropriate forum. i have two compile/ link issues. [EMAIL PROTECTED] doesn't appear appropriate; most folks there aren't discussing compiler or linker isssues. mod_ssl.so doesn't seem to be linking the openssl libs, like lcrypto, so ldd -r is reporting missing symbols and the server fails in attempts to load the module at run time. i'm compiling 2.0.35 on a variety of solaris boxes, using all/ only Sun tools for building and linking. (/usr/ccs/bin, /opt/SUNWspro/, etc.). while looking for the solution to that problem, i ran into another link error. i'm consistently seeing problems with libtool: /bin/sh /vobs/WEB/src/apache2/src/srclib/apr/libtool --silent --mode=link cc -g -mt -DNO_DBM_REWRITEMAP-DSOLARIS2=6 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT-I. -I/vobs/WEB/src/apache2/src/os/unix -I/vobs/WEB/src/apache2/src/server/mpm/worker -I/vobs/WEB/src/apache2/src/modules/http -I/vobs/WEB/src/apache2/src/modules/proxy -I/vobs/WEB/src/apache2/src/include -I/vobs/WEB/src/apache2/src/srclib/apr/include -I/vobs/WEB/src/apache2/src/srclib/apr-util/include -I/vobs/WEB/ssl_inst/include/openssl -I/vobs/WEB/ssl_inst/include -I/vobs/WEB/src/apache2/src/modules/dav/main -I/vobs/WEB/src/apache2/src/srclib/apr-util/include -I/vobs/WEB/src/apache2/src/srclib/apr-util/xml/expat/lib -export-dynamic -L/vobs/WEB/ssl_inst/lib -R/vobs/WEB/ssl_inst/lib -o httpd modules.lo -L/vobs/WEB/ssl_inst/lib -R/vobs/WEB/ssl_inst/lib modules/http/mod_http.la modules/mappers/mod_so.la server/mpm/worker/libworker.la server/libmain.la os/unix/libos.la /vobs/WEB/src/apache2/src/srclib/pcre/libpcre.la /vobs/WEB/src/apache2/src/srclib/apr-util/libaprutil.la /vobs/WEB/src/apache2/src/srclib/apr/libapr.la -lm -lsocket -lnsl -lresolv -ldl -lssl -lcrypto /vobs/WEB/src/apache2/src/srclib/apr-util/xml/expat/lib/libexpat.la ild: calling ld to finish link -- (internal error) ranlib_library() unexpected EL_UNINITIALIZED : modules/http/.libs/mod_http.al has anyone seen this problem? i am poking at libtool, etc. to attempt to solve this problem, but any help is greatly appreciated. cheers, andy
