CVE-2019-12412: libapreq2 null pointer dereference
CVE-2019-12412: libapreq2 null pointer dereference Severity: important Vendor: The Apache Software Foundation Versions Affected: libapreq2 2.07 to 2.13 Description: In libapreq2 versions 2.07 through 2.13 inclusive, a flaw in the multipart parser can deference a null pointer leading to a process crash. A remote attacker could send a request causing a process crash which could lead to a denial of service attack. Mitigation: disable the libapreq2 multipart parser Credit: Thanks to Max Kellerman and Salvatore Bonaccorso for finding and reporting this issue. References: https://bugs.debian.org/939937
[ANNOUNCE] libapreq2-2.15 Released
libapreq2-2.15 Released The Apache Software Foundation and The Apache HTTP Server Project are pleased to announce the 2.15 release of libapreq2. This Announcement notes significant changes introduced by this release. libapreq2-2.15 is released under the Apache License version 2.0. It is now available through the ASF mirrors https://httpd.apache.org/apreq/download.cgi libapreq2 is an APR-based shared library used for parsing HTTP cookies, query-strings and POST data. This package provides 1) version 2.8.1 of the libapreq2 library, 2) mod_apreq2, a filter module necessary for using libapreq2 within the Apache HTTP Server, 3) the Apache2::Request, Apache2::Cookie, and Apache2::Upload perl modules for using libapreq2 with mod_perl2. Changes with libapreq2-2.15 (released November 12, 2020) - SECURITY: CVE-2019-12412 (cve.mitre.org) C API [Max Kellermann] Fix a NULL pointer dereference when parsing malformed multipart data in apreq_parse_multipart(). - C API [Yann Ylavic] In apreq_brigade_concat(), fix memory handling and create the FILE bucket correctly. - Build [Petr Pisar] Fix "make release" on Unix.
Re: [RELEASE CANDIDATE] Apache-Test-1.41 RC1
On Wed, Jul 03, 2019 at 08:45:36AM +0100, Steve Hay wrote: > Please download, test, and report back on this Apache-Test 1.41 > release candidate. > > https://dist.apache.org/repos/dist/dev/perl/Apache-Test-1.41-rc1.tar.gz > > MD5 = 7933d3a6a762f087bf7883a1ac2086eb > SHA1 = 17aa9a8669023aa2f485aa83f8f389969b8e5f0c I can't remember if I'm a PMC member for perl.a.o but +1 for release from me, this looks good to me. Regards, Joe
Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS include/http_core.h modules/filters/mod_include.c server/config.c server/core.c
On Thu, May 21, 2009 at 02:39:57PM -0400, Jeff Trawick wrote: On Wed, May 20, 2009 at 8:53 AM, Joe Orton jor...@redhat.com wrote: Given that the semantics of the options has changed, I don't think it's worth changing httpd to maintain any pretence of compile-time or run-time compatibility here. Any code using the OPT_* constants as exposed by mod_perl cannot work as expected any more. Is the change in semantics required to fix the bug, or is it simply the current implementation? Attaching my original analysis for security@ which hopefully answers that question ;) Having thought about this longer, I do agree that it would be reasonable to provide OPT_INCNOEXEC as a noop integer for back-compat, but, it turns out we're out of bits - allow_options_t is an unsigned char and we're using 2^0 through 2^7 already. :( The only available option is to #define OPT_INCNOEXEC to some bogus string or something; not sure I like that much better than just a clean break. Worth noting: for any mod_perl-based code which tests only OPT_INCLUDE for is SSI enabled, that will continue to be compatible with the new implementation, modulo mod_perl build failures. The only issue is with code which needs to differentiate between SSI-with-exec and -without. Regards, Joe
Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS include/http_core.h modules/filters/mod_include.c server/config.c server/core.c
On Fri, May 22, 2009 at 05:26:07PM +0100, Joe Orton wrote: Attaching my original analysis for security@ which hopefully answers that question ;) attempt 2 I've now had a deeper look into this. I can't see a way to fix the problem without changing the semantics of the OPT_ bits used, as I mentioned briefly in my comment to Vincent. Status quo: a) OPT_INCLUDES is interpreted as SSI is allowed with exec= b) OPT_INCNOEXEC is interperted iff OPT_INCLUDES is also set as meaning SSI is allowed but exec= is not c) setting AllowOverride Options=IncludesNoExec results in both OPT_INCLUDES and OPT_INCNOEXEC being set in the -override_opts bitmask, i.e. either or both options can be overridden in .htaccess files From this leads the fact that an .htaccess file can set simply Options Includes in a context which inherits AllowOverride Options=IncludesNoExec. I'm presuming nobody will argue that's a feature not a bug? If so, I think this is the set of constraints which need to be satisfied: 1) the result of a config merge with only Options IncludesNoEXEC specified must not allow use of exec= in SSI 2) if AllowOverride Options= is used without Includes, notably, use of AllowOverride Options=IncludesNoExec, use of Options Includes in an .htaccess file must be an error 3) if AllowOverride Options=Includes is set, use of both Options Includes and Options IncludesNoExec must succeed and enable SSI with or without exec= respectively 4) if permitted by AllowOverride, setting Options Includes in a context from which Options IncludesNoExec is inherited, then the result must be one where exec= is allowed. Attached is a patch which passes the tests I have so far - Vincent, can you easily re-run your tests used to produce that lovely matrix, with this applied? Regards, Joe
Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS include/http_core.h modules/filters/mod_include.c server/config.c server/core.c
On Sun, May 17, 2009 at 11:15:00AM -0400, Jeff Trawick wrote: On Tue, May 12, 2009 at 9:17 AM, cove...@apache.org wrote: Author: covener Date: Tue May 12 13:17:29 2009 New Revision: 773881 URL: http://svn.apache.org/viewvc?rev=773881view=rev Log: backport 772997, 773322, 773342 from trunk. Reviewed By: jorton, rpluem, covener Security fix for CVE-2009-1195: fix Options handling such that 'AllowOverride Options=IncludesNoExec' does not permit Includes with exec= enabled to be configured in an .htaccess file: * include/http_core.h: Change semantics of Includes/IncludeNoExec options bits to be additive; OPT_INCLUDES now means SSI is enabled without exec=. OPT_INCLUDES|OPT_INC_WITH_EXEC means SSI is enabled with exec=. Current mod_perl tarballs reference OPT_INC_WITH_EXEC as part of mapping the httpd API into perl, and the mod_perl build fails because of this. (modperl_config.c, line 525: undefined symbol: OPT_INCNOEXEC) Ick :( For some reason I thought this was hidden by CORE_PRIVATE, for what little that's worth. While I don't understand why the mod_perl mappings are created at release time against who knows what httpd, it brings up an interesting httpd issue anyway. If some module does have OPT_INCNOEXEC baked in (32), it matches what 2.2.12+ thinks is OPT_INC_WITH_EXEC. Similarly, the old OPT_INC_WITH_EXEC (previously called OPT_INCLUDES), maps what 2.2.12+ thinks is OPT_INCLUDES-without-exec. We could swap the values of OPT_INCLUDES and OPT_INC_WITH_EXEC to lessen the chance of some theoretical module making the wrong decision. We can also define OPT_INCNOEXEC to something (either the new OPT_INCLUDES or Get your mod_perl patch at XXX). Given that the semantics of the options has changed, I don't think it's worth changing httpd to maintain any pretence of compile-time or run-time compatibility here. Any code using the OPT_* constants as exposed by mod_perl cannot work as expected any more. Regards, Joe
Re: [RELEASE CANDIDATE] mod_perl-2.0.4 RC1
On Tue, Apr 01, 2008 at 11:26:43PM -0700, Philippe M. Chiasson wrote: The mod_perl 2.0.4 release candidate 1 Works with Perl 5.10 is ready. It can be downloaded here: http://www.apache.org/~gozer/mp2/mod_perl-2.0.4-rc1.tar.gz MD5: 1f0a941e8b5f26b6102126ae67ddbb43 SHA1: 8b2ceede3c783b9b2cc9e0fe63a095b0e4a1f000 Please give it a spin in your favorite configuration and report any problems. Especially needed against Perl-5.10 on Windows. v5.8.8 on Fedora 8/x86_64, testing against httpd 2.2.9-dev got: t/modules/include_subreq.t11 100.00% 1 3 tests and 1 subtest skipped. Failed 1/238 test scripts, 99.58% okay. 1/2683 subtests failed, 99.96% okay. the failure was: t/modules/include_subreq1..1 # Running under perl version 5.008008 for linux # Current time local: Wed Apr 2 15:11:56 2008 # Current time GMT: Wed Apr 2 14:11:56 2008 # Using Test.pm version 1.25 # Using Apache/Test.pm version 1.31 # Failed test 1 in t/modules/include_subreq.t at line 17 # testing : handler = filter = handler # expected: subreq is quite ok # received: is quite subreq ok not ok 1 is that a known issue? joe
Re: [mp2] make test fails: failed to map segment from shared object: Operation not permitted
On Thu, Jan 19, 2006 at 09:35:30PM -0600, Eamon Daly wrote: 1. Problem Description: Hey, all. I'm trying to build mod_perl against the stock httpd in RedHat 4ES. The build runs without issue, but make test fails immediately with the following error: Can't load '/tmp/mod_perl-2.0.2/blib/arch/auto/ModPerl/Const/Const.so' for module ModPerl::Const: /tmp/mod_perl-2.0.2/blib/arch/auto/ModPerl/Const/Const.so: failed to map segment from shared object: Operation not permitted at /usr/lib/perl5/5.8.5/i386-linux-thread-multi/DynaLoader.pm line 230. at /tmp/mod_perl-2.0.2/blib/lib/Apache2/Const.pm line 17 These types of errors are caused by the SELinux policy being enforced for /usr/sbin/httpd. It would be simplest to temporarily disable the part of the policy applied to httpd whilst running the test suite, by doing: setsebool httpd_disable_trans 1 make test setsebool httpd_disable_trans 0 Regards, joe
Re: [mp2] make test errors
On Fri, Feb 18, 2005 at 05:35:56PM -0500, Stas Bekman wrote: Joe, shouldn't the APR API emit some kind of errors in the situation like William has with jail env+ac_cv_o_nonblock_inherited thingy, rather than silently fail? The issue is that the configure test couldn't make a decision, but configure tests are always binary yes/no not yes/no/dunno and that's really the nature of the beast. The only viable solution to this type of problem in general is to ensure that the APR test suite catches it by checking that the determined behaviour matches the actual behaviour; then you can say to people who see these weird mod_perl failures go run the APR test suite and have a simpler path to diagnose the problem. Maybe it already *does* catch this problem, I don't know. joe
Re: [mp2] make test errors
On Thu, Feb 17, 2005 at 03:05:31PM -0500, William McKee wrote: On Thu, Feb 17, 2005 at 04:53:45PM +, Joe Orton wrote: Check for the result of the: checking if O_NONBLOCK setting is inherited from listening sockets test when you run the configure script. I wasn't sure if you were referring to the mod_perl or Apache configure script. When I ran the following command, the setting was no: perl Makefile.PL PREFIX=/usr/local MP_USE_STATIC=1 MP_AP_PREFIX=/usr/local/src/httpd-2.0.53_perl MP_AP_CONFIGURE=--with-mpm=prefork --prefix=/usr/local/apache2_perl The config.log file from that command is temporarily available here[1]. That confirms that the problem: you got a connect() failure when the configure test program attempted to a listener bound to 0.0.0.0 You can try the standalone test program here to reproduce the failure: http://www.apache.org/~jorton/nonblock.c It could be some firewalling thing in how the machine is set up. joe
Re: [mp2] make test errors
On Wed, Feb 16, 2005 at 07:12:11PM -0500, Stas Bekman wrote: Joe, do you have an idea why this doesn't work on FreeBSD 5.3 (in jail environment). I remember last time you've fixed something about some BSD flavor in APR socket lib. Thanks. That was all the non-blocking-vs-blocking stuff. First I'd ask whether or not this fails in a non-chroot environment. A chroot will screw up all kinds of stuff (e.g. the resolver libraries) unless you set it up properly. I presume that httpd+mod_perl were at least configured and built *outside* the chroot? joe
Re: [mp2] make test errors
On Thu, Feb 17, 2005 at 09:18:31AM -0500, William McKee wrote: On Thu, Feb 17, 2005 at 10:39:46AM +, Joe Orton wrote: That was all the non-blocking-vs-blocking stuff. First I'd ask whether or not this fails in a non-chroot environment. A chroot will screw up all kinds of stuff (e.g. the resolver libraries) unless you set it up properly. Any pointers to how my host should properly configure the chroot would be appreciated. Considering that only 17 of 2106 tests failed, it must be pretty good. I've been running Apache 1.3.x under a jail for a couple years now without any problems (though I couldn't tell you if the tests passed; I doubt that they were being run by the Apachetoolbox utility that I was using to build my server). Is building and running Apache within a chroot environment going to be a problem under Apache2? The configure script in 2.0 (actually, the APR library) does several dynamic system check; the test in question which could make these mod_perl tests needs to bind to a port on 127.0.0.1 and connect to it. It sounds like you may have issues with that in your jail. Check for the result of the: checking if O_NONBLOCK setting is inherited from listening sockets test when you run the configure script. It should be yes on FreeBSD. If it's no, then please preserve capture the srclib/apr/config.log file and upload it somewhere so we can check it. Then try: export ac_cv_o_nonblock_inherited=yes or equivalent in your shell then re-run configure and re-build everything and re-run the mod_perl test suites. I presume that httpd+mod_perl were at least configured and built *outside* the chroot? No, it was built inside the jail. I have no access outside of my jail. I think this is a bit optimistic. I would use a proper FreeBSD 5.3 machine somewhere else to build the software, then deploy prebuilt binaries on the production machine inside the jail. joe
Re: cc: Error: modperl_exports.c under Tru64 Unix
On Tue, Dec 14, 2004 at 03:24:30PM -0500, Stas Bekman wrote: Joe Orton wrote: Just make the generated export stub code #ifndef'ed? #ifndef modperl_io_apache_init const void *modperl_hack_io_apache_init = (const void *)modperl_io_apache_init; #endif if the symbol is a macro then there's no point in generating a stub for it anyway... It's not a macro normally, it's a macro only on certain setups. Here it is again: #ifdef PERLIO_LAYERS MP_INLINE void modperl_io_apache_init(pTHX); #else #definemodperl_io_apache_init(pTHX) #endif So that trick of #ifndef, won't work when PERLIO_LAYERS is not defined, right? Since modperl_io_apache_init is always defined but something it's a real symbols at other times it's a macro to keep some compilers happy. I'm not sure what you're asking; the preprecessor doesn't know about C function declarations, it only cares about preprocessor directives. In the above case, the CPP macro modperl_io_apache_init is only defined in the case that PERLIO_LAYERS is not defined. So the fragment: #ifndef modperl_io_apache_init const void *modperl_hack_io_apache_init = (const void*)modperl_io_apache_init; #endif only expands in the case that PERLIO_LAYERS *is* defined, which is the desired outcome, right? joe -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: cc: Error: modperl_exports.c under Tru64 Unix
On Tue, Dec 14, 2004 at 10:27:03AM -0500, Stas Bekman wrote: Joe Orton wrote: On Mon, Dec 13, 2004 at 08:12:19PM -0500, Stas Bekman wrote: In fact we already somewhat handle that in modperl_io_apache.h #ifdef PERLIO_LAYERS [...] MP_INLINE void modperl_io_apache_init(pTHX); #else /* #ifdef PERLIO_LAYERS */ #define modperl_io_apache_init(pTHX) but for some reason define doesn't do the trick, when it gets to do: const void *modperl_hack_io_apache_init = (const void *)modperl_io_apache_init; The C preprocessor won't expand a parameterized macro unless it's called with parameters: $ cpp #define foo(bar) bar foo(norman) foo blah # 1 stdin # 1 built-in # 1 command line # 1 stdin norman foo blah Thanks Joe. So what kind of hack of the hack can we use here? I suppose that even if it did expand it, there would have been a problem since we have: #define modperl_io_apache_init(pTHX) so it expands to nothing. Of course the right solution is to never include this in the autogenerated modperl_exports.c but this will require C parsing with some messy sed like Apache/APR do. Is there some other solution for this kind of functions? Just make the generated export stub code #ifndef'ed? #ifndef modperl_io_apache_init const void *modperl_hack_io_apache_init = (const void *)modperl_io_apache_init; #endif if the symbol is a macro then there's no point in generating a stub for it anyway... joe -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: cc: Error: modperl_exports.c under Tru64 Unix
On Mon, Dec 13, 2004 at 08:12:19PM -0500, Stas Bekman wrote: In fact we already somewhat handle that in modperl_io_apache.h #ifdef PERLIO_LAYERS [...] MP_INLINE void modperl_io_apache_init(pTHX); #else /* #ifdef PERLIO_LAYERS */ #define modperl_io_apache_init(pTHX) but for some reason define doesn't do the trick, when it gets to do: const void *modperl_hack_io_apache_init = (const void *)modperl_io_apache_init; The C preprocessor won't expand a parameterized macro unless it's called with parameters: $ cpp #define foo(bar) bar foo(norman) foo blah # 1 stdin # 1 built-in # 1 command line # 1 stdin norman foo blah -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Repeated kill -HUP to httpd dumps core
On Mon, Dec 06, 2004 at 08:02:22PM +0530, pradeep kumar wrote:
Hi,
I have reported a bug. The bug number is 32542. Looking into
the problem I found that the porblems on both 2.0.43 and 2.0.52 are
same. The perl_alloc funtion which caused the error as seen from the
stack trace of 2.0.52 was found to give the same pthread_key_create
error. As seen by the PerlIO_stderr() function which is after the
perl_alloc funtion in the stack.
Until you actually have any idea what is causing this bug, randomly
opening bug reports is not going to help -- especially not against httpd
since this looks like a custom vendor-patched httpd build.
I suggest the first thing to do is to reproduce the bug with a more
recent version of Perl - as Stas shows, it will give a better diagnostic
in the panic message.
joe
...
I did this
# strings mod_perl.so | grep panic: pthread_key_create
panic: pthread_key_create
# strings /opt/perl/bin/perl | grep panic: pthread_key_create
panic: pthread_key_create
This suggests that the perl interpreter is generating this message.
Where do I proceed from here.
perl-5.8.x/thread.x:
#ifndef ALLOC_THREAD_KEY
# define ALLOC_THREAD_KEY \
STMT_START { \
int _eC_; \
if ((_eC_ = pthread_key_create(PL_thr_key, 0))) { \
PerlIO_printf(PerlIO_stderr(), panic: pthread_key_create (%d)
[%s:%d], \
_eC_, __FILE__, __LINE__); \
exit(1);\
} \
} STMT_END
#endif
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Handler Order
On Tue, Nov 02, 2004 at 08:37:42PM -0500, Geoffrey Young wrote: Did you try #include'ing mod_ssl.h to pick up the optional function declarations rather than copy'n'pasting them? It should work OK with recent 2.0 releases. ... /apache/2.0.52/ssl/perl-5.8.5/include/mod_ssl.h:91:17: ssl.h: No such file or directory In file included from /apache/2.0.52/ssl/perl-5.8.5/include/mod_ssl.h:92, from SSLLookup.xs:5: which I gather is because mod_perl does not include the -I/usr/include/openssl that apache does when I activate mod_ssl. I can't find the list of includes in apxs or apr-config either, so I'm not sure how we could expect mod_perl to retain this information and pass it along in WriteMakefile. I'm not really the best at this kind of thing, so suggestions welcome. otherwise, I guess the declaration stays. Fair enough, yes, it's probably in there somewhere but apxs in 2.0 is not most helpful about this stuff... as an aside, do you know why mod_rewrite doesn't list mod_ssl as a predecessor when calling register_hooks? it would seem that mod_rewrite could be loaded after mod_ssl and thus not get access to those optional functions. but I've only used the optional stuff a few times, mainly with mod_include's stuff, so maybe things are different here. The optional functions are registered in a pre_config hook and extracted in a post_config hook which ensures that (I presume this is true for mod_ssl, haven't checked). joe -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Handler Order
On Tue, Nov 02, 2004 at 04:49:55PM -0500, Geoffrey Young wrote: I've been meaning to take care of this since you mentioned it. http://www.modperlcookbook.org/~geoff/modules/Apache-SSLLookup-2.00_01.tar.gz I'll probably move it to cpan in the next day or so. Very nice! Now can I just borrow some of your round tuits? Did you try #include'ing mod_ssl.h to pick up the optional function declarations rather than copy'n'pasting them? It should work OK with recent 2.0 releases. joe -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Apache2: undefined symbol: PL_localizing
On Mon, Oct 11, 2004 at 11:47:33PM +0200, MARTIN Pierre wrote: Please do: cd src/modules/perl/ rm mod_perl.so make -f Makefile.modperl Here we go: /data/misc/mod_perl-1.99_16/src/modules/perl# rm mod_perl.so /data/misc/mod_perl-1.99_16/src/modules/perl# make -f Makefile.modperl rm -f mod_perl.so cc -shared -L/usr/local/lib \ ... ags.lo modperl_xsinit.lo -rdynamic -L/usr/local/lib /usr/lib/perl/5.6.1/auto/D ynaLoader/DynaLoader.a -L/usr/lib/perl/5.6.1/CORE -lperl -ldl -lm -lc -lcryp t \ -o mod_perl.so : mod_perl.so This problem is probably caused by a bogus libperl.a on your system somewhere. What does: ls -l /usr/lib/perl/5.6.1/CORE/libperl.* /usr/lib/libperl.* \ /usr/local/lib/libperl.* give? joe -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Apache2: undefined symbol: PL_localizing
On Wed, Oct 13, 2004 at 08:26:43AM -0400, Stas Bekman wrote: Joe Orton wrote: This problem is probably caused by a bogus libperl.a on your system somewhere. What does: ls -l /usr/lib/perl/5.6.1/CORE/libperl.* /usr/lib/libperl.* \ /usr/local/lib/libperl.* give? IMHO, it's libperl.so the linker is after, not libperl.a, since it's -rdynamic -lperl. -rdynamic is an obsolete gcc alias for -Wl,--export-dynamic, and has no effect on whether the linker uses static or dynamically loaded libraries for -l options. (in fact it's completely redundant when linking a shared object like mod_perl as far as I'm aware) If -lperl was specified on the link line and ldd does not show a dependency on libperl.so.N, then barring a complete linker fubar, it must be the case that a libperl.a was linked statically. joe -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Apache2: undefined symbol: PL_localizing
On Wed, Oct 13, 2004 at 05:02:30PM -0400, Stas Bekman wrote: Joe Orton wrote: If -lperl was specified on the link line and ldd does not show a dependency on libperl.so.N, then barring a complete linker fubar, it must be the case that a libperl.a was linked statically. I doubt that this is the case, because I asked Martin to run nm on mod_perl.so and perl symbols were unresolved. Please see: http://article.gmane.org/gmane.comp.apache.mod-perl/15266 Yes, I read the whole thread, this seems consistent with linking against a bogus libperl.a on the system (maybe from a different version of Perl) which doesn't define all the symbols which mod_perl needs. That seems far more likely than the linker being so borked it ignores -l flags. joe -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Handler Order
On Fri, Oct 08, 2004 at 02:42:49PM +0200, Torsten Frtsch wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I know one can specify the handler invocation order of the request phases. But
how to do it?
My problem is, I want to know if a request came in over http or https in the
fixup phase. With mp1 I had configured by the LoadModule order that a
mod_perl handler was called after the mod_ssl handler. Since mod_ssl sets up
subprocess_env in the fixup phase I could check subprocess_env('HTTPS') in a
mod_perl fixup handler.
How can I define that my mod_perl fixup handler is to be called after the
mod_ssl fixup handler?
Or how can I access the SSL related stuff from mod_perl prior to the response
phase?
The best thing to do is to use the ssl_var_lookup hook which the C
interface to mod_ssl exports, or better yet, if using 2.0.51 or later,
the ssl_is_https hook. This means you don't have to use SSLOptions
+StdEnvVars to get SSL variables via subprocess_env, which adds a lot
of overhead since you probably don't need most of them, and the hook
orderings don't matter.
You'd have to right Perl bindings for this first of course!
joe
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors
On Wed, Sep 22, 2004 at 10:17:34PM -0400, Stas Bekman wrote: Joe, as 2.0.52 is about to be released. Can that fix for NetBSD applied to the 0.9 trunch (and head) if it does the trick? Thanks. It's been in both branches for a while so hopefully it will get picked up, yep. joe -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors
On Fri, Sep 17, 2004 at 04:15:23PM -0400, Stas Bekman wrote:
So is that the right skip rule (hoping that 2.0.52 will fix NetBSD:
my $should_skip =
($^0 eq /^OpenBSD$/i !need_min_apache_version('2.0.51')) ||
($^0 eq /^NetBSD$/i !need_min_apache_version('2.0.52'));
That logic is correct w.r.t the APR issue, yes.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors
On Wed, Sep 15, 2004 at 05:15:05PM +1000, Carl Brewer wrote: Joe Orton wrote: Oh well, having found a NetBSD box to testd this myself, the NetBSD fcntl() is being economical with the truth. It doesn't return O_NONBLOCK yet the socket really is non-blocking. I'll put in the suggested apr_hints.m4 change. fun fun This may be worth bringing to the attention of the NetBSD core team, as there's a 2.0 release coming up pretty soon, it may be a bugfix worth including. yah, http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=26950 joe -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors
I can try and debug this, I've found a NetBSD machine and reproduced the failure. ./t/TEST -start-httpd doesn't work from the mod_perl test suite, is there a way to get that working? bash-2.05b$ ./t/TEST -start-httpd /tmp/jorton12/root/bin/httpd -d /tmp/jorton12/mod_perl-1.99_16/t -f /tmp/jorton12/mod_perl-1.99_16/t/conf/httpd.conf -D APACHE2 using Apache/2.0.51-dev (prefork MPM) waiting 120 seconds for server to start: .[Tue Sep 14 15:53:52 2004] [info] 27 Apache:: modules loaded [Tue Sep 14 15:53:52 2004] [info] 7 APR:: modules loaded [Tue Sep 14 15:53:52 2004] [info] base server + 20 vhosts ready to run tests [Tue Sep 14 15:53:53 2004] [error] Can't locate ApacheTest/PerlModuleTest.pm in @INC (@INC contains: /tmp/jorton12/mod_perl-1.99_16/t/lib /tmp/jorton12/mod_perl-1.99_16/Apache-Test/lib /tmp/jorton12/mod_perl-1.99_16/t/response /tmp/jorton12/mod_perl-1.99_16/t/protocol /tmp/jorton12/mod_perl-1.99_16/t/preconnection /tmp/jorton12/mod_perl-1.99_16/t/hooks /tmp/jorton12/mod_perl-1.99_16/t/filter /tmp/jorton12/mod_perl-1.99_16/t /tmp/jorton12/mod_perl-1.99_16/t/htdocs/testdirective/main /tmp/jorton12/mod_perl-1.99_16/t/htdocs/testdirective/perlmodule-vh /tmp/jorton12/mod_perl-1.99_16/t/ /tmp/jorton12/mod_perl-1.99_16/t/lib/perl /tmp/jorton12/mod_perl-1.99_16/blib/lib /tmp/jorton12/mod_perl-1.99_16/blib/arch /usr/pkg/lib/perl5/site_perl/5.8.0/i386-netbsd /usr/pkg/lib/perl5/site_perl/5.8.0 /usr/pkg/lib/perl5/site_perl /usr/pkg/lib/perl5/5.8.0/i386-netbsd /usr/pkg/lib/perl5/5.8.0) at (eval 60) line 3.\n [Tue Sep 14 15:53:53 2004] [error] Can't load Perl module ApacheTest::PerlModuleTest for server localhost:8549, exiting... -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors
On Thu, Sep 09, 2004 at 05:40:48PM +0400, [EMAIL PROTECTED] wrote: k714% ./nonblock found port: 52984 O_NONBLOCK is not set in the child. This is rather confusing, since it means that apparently the test is working OK, and O_NONBLOCK is *not* inherited across accept() on NetBSD, which contradicts the behaviour you are seeing. same on netbsd-1.6.1 k133% ./nonblock found port: 65534 O_NONBLOCK is not set in the child. k133% Oh well, having found a NetBSD box to testd this myself, the NetBSD fcntl() is being economical with the truth. It doesn't return O_NONBLOCK yet the socket really is non-blocking. I'll put in the suggested apr_hints.m4 change. fun fun -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors
On Tue, Sep 07, 2004 at 08:25:03AM -0700, Ken Simpson wrote: I wasn't surprised this fails on OpenBSD but I am surprised it fails on NetBSD. Can you compile and run: http://www.apache.org/~jorton/nonblock.c and post the output. (it would be useful if you could do this on OpenBSD too, Ken, for verification) -bash-2.05b$ ./nonblock connect: Invalid argument Thanks, I had not remembered the issue correctly... The problem is that getsockname() does not return the real port number for a socket bound to an ephemeral port on OpenBSD. So the apr_hints.m4 change is correct for this issue since the autoconf test can't work. joe -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors
On Thu, Sep 09, 2004 at 11:38:15AM +0400, [EMAIL PROTECTED] wrote: I wasn't surprised this fails on OpenBSD but I am surprised it fails on NetBSD. Can you compile and run: http://www.apache.org/~jorton/nonblock.c and post the output. (it would be useful if you could do this on OpenBSD too, Ken, for verification) sorry for the dealy -- was away from my PC for a day k714% ./nonblock found port: 52984 O_NONBLOCK is not set in the child. This is rather confusing, since it means that apparently the test is working OK, and O_NONBLOCK is *not* inherited across accept() on NetBSD, which contradicts the behaviour you are seeing. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors
On Tue, Sep 07, 2004 at 08:58:26AM -0400, Stas Bekman wrote: [EMAIL PROTECTED] wrote: I'd put my $5.00 on APR being the cause of this problem. Mikhail, you will probably need to patch APR when you build Apache. Try this patch, which I am guessing will work on NetBSD: I wasn't surprised this fails on OpenBSD but I am surprised it fails on NetBSD. Can you compile and run: http://www.apache.org/~jorton/nonblock.c and post the output. (it would be useful if you could do this on OpenBSD too, Ken, for verification) joe -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors
On Tue, Sep 07, 2004 at 03:49:59PM -0400, Stas Bekman wrote: Ken Simpson wrote: Ken, Stas, done as advised. The only test which is failing now (and was failing before) is: Mikhail, Ken, please submit that patch to dev /at/ apr.apache.org http://apr.apache.org/. Hopefully it'll get into 2.0.51 release. Or may be it's too late. The patch has already gone into APR CVS. I thought that patch was only for OpenBSD. Is that not the case? That's correct, this is currently fixed only for OpenBSD, and I'd prefer to see the output of the test case on NetBSD to see why it fails there before proceeding to use the same fix for that platform. joe -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
