Change to Module DB
User ID : 325 Title: DACS Details : https://modules.apache.org/search.php?id=834
RE: svn commit: r1302444 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy.c
-Original Message- From: Jim Jagielski Sent: Montag, 19. März 2012 20:16 To: dev@httpd.apache.org Subject: Re: svn commit: r1302444 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy.c Cool.. Are these candidates for 2.4.x? Yes, but currently ENOTIME for backport proposals. So if you want... Regards Rüdiger
Re: /bin/sh: ./gen_test_char: cannot execute binary file
Hi Guenter, I can give it a try. Kind Regards, Henrik On Sat, 2012-03-17 at 12:01 +0100, Guenter Knauf wrote: Hi Henrik, Am 16.03.2012 15:07, schrieb Henrik Strand: This error has been around for 10 years or so, but I could not find an error report on this issue so I created one (in May, 2011): https://issues.apache.org/bugzilla/show_bug.cgi?id=51257 There exists an old (2003-08-13) patch (http://marc.info/?l=apache-httpd-devm=106150997309208w=2) for this error but I do not think that it was integrated. Another patch (http://svn.apache.org/viewvc/httpd/httpd/trunk/server/gen_test_char.c?r1=758929r2=795438pathrev=1001398diff_format=h) has recently been integrated to simplify cross-compilation. However, this patch does not solve the gen_test_char cross-compiling issue. A known workaround is to: 1. Cross-compile and wait for the build to fail. 2. Compile for build system and copy the gen_test_char binary to the cross-compiled build folder 3. Run make a second time for the cross-compiled system However, since I'm about to automate the build process this workaround is not sufficient for me. this step with another 3 rounds of configure (APR, APU, httpd) + compilation of APR/APU isnt really necessary; instead just compile gen_test_char.c 1st with something like: gcc -Wall -O2 -DCROSS_COMPILE gen_test_char.c -s -o gen_test_char then run it and put its output into the include folder (or where its placed normaly); I believe you can then make it with only one go + automatically ... It seems strange that this error has been around for so long time so I'm wondering if the Httpd build system does include some way to generate a correct gen_test_char file when cross-compiling? nope; in order to make it the clean way we would need to have an --host option to configure ... I looked at the old 2003 patch which is for AP 1.3, and it looks harmless, and could perhaps be integrated - are you up to provide a patch for trunk? BTW. how is the cross-compilation of PCRE handled? There's a similar case where a build helper is needed for generating chartables.c? Gün.
Re: TRACE still enabled by default
On Saturday 17 March 2012, Roy T. Fielding wrote: We still enable TRACE by default. Is this useful enough to justify making every other poor sap with a security scanner have to manually turn it off? Yes. I'm hoping 2.4.x is early enough in life where flipping this wouldn't be too astonishing. I don't change protocols based on fool security researchers and their failure to correctly direct security reports. TRACE is not a vulnerability. That doesn't mean that it's a good idea to have it on by default. I can't remember ever having needed it for debugging. While it may actually be useful in reverse-proxy situations, it is usually necessary to disable it there because one does not want to leak internal information like the private IPs from X-Forwarded-For. It can also compound security issues in webapps. In general, one can say that it increases the attack surface a web server presents to the internet. I think it is a good idea to make it default to off.
Re: TRACE still enabled by default
On 2012-03-20 20:04, Stefan Fritsch wrote: ... It can also compound security issues in webapps. In general, one can ^^^ How so? When you say webapps, are you referring to something not running via script/XHR? Best regards, Julian
Re: TRACE still enabled by default
On Tuesday 20 March 2012, Julian Reschke wrote: How so? When you say webapps, are you referring to something not running via script/XHR? Sorry, I meant to write browser plugins instead of webapps.
Re: svn commit: r1302856 - /httpd/httpd/branches/2.4.x/docs/manual/mod/core.xml
On 3/20/2012 7:09 AM, j...@apache.org wrote: Author: jim Date: Tue Mar 20 12:09:05 2012 New Revision: 1302856 URL: http://svn.apache.org/viewvc?rev=1302856view=rev Log: Merge r1302855 from trunk: Note that TRACE is not a vuln Agreed. +pDespite claims to the contrary, codeTRACE/code is not +a security vulnerability and there is no viable reason for +it to be disabled. Doing so necessarily makes your server +non-compliant./p I'm not clear that's true. http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-6.8 currently in last call has plenty to say about TRACE. It doesn't document a MUST requirement for a server to support TRACE requests. It reads (at least to me, anyways) that support of TRACE is a good idea. It has some comments on security implications, as well, in that document.
Re: svn commit: r1302856 - /httpd/httpd/branches/2.4.x/docs/manual/mod/core.xml
On Tue, Mar 20, 2012 at 8:09 AM, j...@apache.org wrote: Author: jim Date: Tue Mar 20 12:09:05 2012 New Revision: 1302856 URL: http://svn.apache.org/viewvc?rev=1302856view=rev Log: Merge r1302855 from trunk: Note that TRACE is not a vuln +nameDefaultRuntimeDir/name +descriptionBase directory for the server run-time files/description +syntaxDefaultRuntimeDir vardirectory-path/var/syntax +defaultDefaultRuntimeDir DEFAULT_REL_RUNTIMEDIR (logs/)/default +contextlistcontextserver config/context/contextlist half of this commit seem inadvertent
Re: svn commit: r1302856 - /httpd/httpd/branches/2.4.x/docs/manual/mod/core.xml
On 3/20/2012 4:28 PM, William A. Rowe Jr. wrote: On 3/20/2012 7:09 AM, j...@apache.org wrote: Author: jim Date: Tue Mar 20 12:09:05 2012 New Revision: 1302856 URL: http://svn.apache.org/viewvc?rev=1302856view=rev Log: Merge r1302855 from trunk: Note that TRACE is not a vuln Agreed. +pDespite claims to the contrary, codeTRACE/code is not +a security vulnerability and there is no viable reason for +it to be disabled. Doing so necessarily makes your server +non-compliant./p I'm not clear that's true. http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-6.8 currently in last call has plenty to say about TRACE. It doesn't document a MUST requirement for a server to support TRACE requests. It reads (at least to me, anyways) that support of TRACE is a good idea. It has some comments on security implications, as well, in that document. And looking at that document again, there is very little variation between TRACE and DELETE to suggest that TRACE must be implemented, but that we can leave DELETE unimplemented. CONNECT, on the other hand, is very clear about how unlikely it is to be implemented on origin servers.
Re: Cannot start httpd v2.4.1 with mpm_build on AIX
Hi Michael, Am 18.03.2012 19:16, schrieb Michael Felt: I hope 2.4.2 can wait for the patch! I shall cherish my patched source tree for now then. I've just comitted the patch with r1303201 - please verify that it still works for ya! Jeff, please take aso a look and check if I did catch all ... Gregg, can you please run a Windows build? Gün.
Re: Cannot start httpd v2.4.1 with mpm_build on AIX
Gün, It Works! On 3/20/2012 4:18 PM, Guenter Knauf wrote: Gregg, can you please run a Windows build? Gün.
