Fwd: svn commit: r1179448 - in /httpd/httpd/trunk: include/ap_mmn.h include/mpm_common.h server/mpm_common.c
Original-Nachricht Betreff: svn commit: r1179448 - in /httpd/httpd/trunk: include/ap_mmn.h include/mpm_common.h server/mpm_common.c Datum: Wed, 05 Oct 2011 21:25:59 GMT Von: Author: sf Date: Wed Oct 5 21:25:58 2011 New Revision: 1179448 URL: http://svn.apache.org/viewvc?rev=1179448view=rev Log: Export ap_max_mem_free, needed by r1178079, as pointed out by Gregg L. Smith Modified: httpd/httpd/trunk/include/ap_mmn.h httpd/httpd/trunk/include/mpm_common.h httpd/httpd/trunk/server/mpm_common.c Modified: httpd/httpd/trunk/include/ap_mmn.h URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_mmn.h?rev=1179448r1=1179447r2=1179448view=diff == --- httpd/httpd/trunk/include/ap_mmn.h (original) +++ httpd/httpd/trunk/include/ap_mmn.h Wed Oct 5 21:25:58 2011 @@ -355,6 +355,7 @@ * 20110724.8 (2.3.15-dev) add ap_abort_on_oom(), ap_malloc(), ap_calloc(), * ap_realloc() * 20110724.9 (2.3.15-dev) add ap_varbuf_pdup() and ap_varbuf_regsub() + * 20110724.10(2.3.15-dev) Export ap_max_mem_free */ #define MODULE_MAGIC_COOKIE 0x41503234UL /* AP24 */ @@ -362,7 +363,7 @@ #ifndef MODULE_MAGIC_NUMBER_MAJOR #define MODULE_MAGIC_NUMBER_MAJOR 20110724 #endif -#define MODULE_MAGIC_NUMBER_MINOR 9/* 0...n */ +#define MODULE_MAGIC_NUMBER_MINOR 10 /* 0...n */ /** * Determine if the server's current MODULE_MAGIC_NUMBER is at least a Modified: httpd/httpd/trunk/include/mpm_common.h URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/include/mpm_common.h?rev=1179448r1=1179447r2=1179448view=diff == --- httpd/httpd/trunk/include/mpm_common.h (original) +++ httpd/httpd/trunk/include/mpm_common.h Wed Oct 5 21:25:58 2011 @@ -314,7 +314,7 @@ AP_INIT_TAKE1(GracefulShutdownTimeout, int ap_signal_server(int *, apr_pool_t *); void ap_mpm_rewrite_args(process_rec *); -extern apr_uint32_t ap_max_mem_free; +AP_DECLARE_DATA apr_uint32_t ap_max_mem_free; Shouldn't that be extern apr_uint32_t AP_DECLARE_DATA ap_max_mem_free; extern const char *ap_mpm_set_max_mem_free(cmd_parms *cmd, void *dummy, const char *arg); Modified: httpd/httpd/trunk/server/mpm_common.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm_common.c?rev=1179448r1=1179447r2=1179448view=diff == --- httpd/httpd/trunk/server/mpm_common.c (original) +++ httpd/httpd/trunk/server/mpm_common.c Wed Oct 5 21:25:58 2011 @@ -142,7 +142,7 @@ int ap_max_requests_per_child; char ap_coredump_dir[MAX_STRING_LEN]; int ap_coredumpdir_configured; int ap_graceful_shutdown_timeout; -apr_uint32_t ap_max_mem_free; +AP_DECLARE_DATA apr_uint32_t ap_max_mem_free; Shouldn't that be apr_uint32_t AP_DECLARE_DATA ap_max_mem_free; apr_size_t ap_thread_stacksize; /* Set defaults for config directives implemented here. This is
Re: PATCH mod_fcgid compile fails
sorry for my noise. just cleaned up my build tree and tried from the beginning. no more compile errors. thx for your help Stefan
Re: Improving SSL config
Hi Bill, On 02.10.2011 09:07, William A. Rowe Jr. wrote: On 9/29/2011 9:31 AM, Rainer Jung wrote: In light of the TLS 1.0 CBC attack (aka BEAST, CVE-2011-3389) I suggest we update our SSL configuration analogous to what's in trunk. - Choose a better default SSLCipherSuite - Add SSLHonorCipherOrder - restrict MSIE exceptions to MSIE 2-5 -1 in this respect; faster is not more secure. We must default to setting the strictest cipher choices, with a commented-out this is faster, but far less secure alternative for those with less targeted assets. If someone is enabling mod_ssl, it is to secure their traffic, not to speed up their server. And no, MD4, although immune to *this* vector, is simply not preferable. Our current 2.2.x SSLCipherSuite contains e.g. SSLv2 and export ciphers. So there is a need to improve. My suggestion is a straight backport from trunk. So what is the strictest cipher choice you suggest? Regards, Rainer
Re: Improving SSL config
On 06.10.2011 10:58, Rainer Jung wrote: Hi Bill, On 02.10.2011 09:07, William A. Rowe Jr. wrote: On 9/29/2011 9:31 AM, Rainer Jung wrote: In light of the TLS 1.0 CBC attack (aka BEAST, CVE-2011-3389) I suggest we update our SSL configuration analogous to what's in trunk. - Choose a better default SSLCipherSuite - Add SSLHonorCipherOrder - restrict MSIE exceptions to MSIE 2-5 -1 in this respect; faster is not more secure. We must default to setting the strictest cipher choices, with a commented-out this is faster, but far less secure alternative for those with less targeted assets. If someone is enabling mod_ssl, it is to secure their traffic, not to speed up their server. And no, MD4, although immune to *this* vector, is simply not preferable. Our current 2.2.x SSLCipherSuite contains e.g. SSLv2 and export ciphers. So there is a need to improve. My suggestion is a straight backport from trunk. So what is the strictest cipher choice you suggest? I might have misunderstood you. Are you only worried about *activating* SSLHonorCipherOrder? Note that in trunk and as proposed here the corresponding comment and config block is commented, so not active by default. See my original post. Regards, Rainer
2.0.65
Would like to TR this week… we have 2 showstoppers awaiting just 1 vote each to be backport-able.
Re: Change loglevel of File does not exist messages
On Oct 5, 2011, at 7:07 PM, Daniel Ruggeri wrote: On 10/5/2011 4:18 PM, Stefan Fritsch wrote: True. But a generic apparatus for even more fine-grained log configuration won't happen in time for 2.4. I have toyed with the idea of this... do you have suggestions on how this might be implemented? One of the ideas I heard (or thought of - don't recall) was to implement an error log filter such that messages matching a certain regex get dropped. To me that seems like it would be very expensive for busier sites, but would serve the purpose for some of the user base. It would be quite expensive to be sure… for some sites, logging is the most expensive part of the server.
Re: 2.0.65
On 10/6/2011 8:08 AM, Jim Jagielski wrote: Would like to TR this week… we have 2 showstoppers awaiting just 1 vote each to be backport-able. And a third bug report at security@ (vulnerability is dubious, but it's still a bug ;-)
Caching - Generating E-Tags
Hi Dev, I'm working on a caching protocol similar to HTTP on a different research. I have the following question regarding the e-tags. When does exactly apache computes the e-tag for a certain resource? Does it compute that when there is a request for that particular resource or is it computed by the server whenever a resource get modified in the server? Thanks, Amila
Re: 2.0.65
On Oct 6, 2011, at 12:49 PM, William A. Rowe Jr. wrote: On 10/6/2011 8:08 AM, Jim Jagielski wrote: Would like to TR this week… we have 2 showstoppers awaiting just 1 vote each to be backport-able. And a third bug report at security@ (vulnerability is dubious, but it's still a bug ;-) Yeppers… Did you see my assessment and suggested fix?
Re: Fwd: svn commit: r1179448 - in /httpd/httpd/trunk: include/ap_mmn.h include/mpm_common.h server/mpm_common.c
On Thu, 6 Oct 2011, Rüdiger Plüm wrote: Author: sf Date: Wed Oct 5 21:25:58 2011 New Revision: 1179448 URL: http://svn.apache.org/viewvc?rev=1179448view=rev Log: Export ap_max_mem_free, needed by r1178079, as pointed out by Gregg L. Smith Modified: httpd/httpd/trunk/include/ap_mmn.h httpd/httpd/trunk/include/mpm_common.h httpd/httpd/trunk/server/mpm_common.c Modified: httpd/httpd/trunk/include/mpm_common.h URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/include/mpm_common.h?rev=1179448r1=1179447r2=1179448view=diff == --- httpd/httpd/trunk/include/mpm_common.h (original) +++ httpd/httpd/trunk/include/mpm_common.h Wed Oct 5 21:25:58 2011 @@ -314,7 +314,7 @@ AP_INIT_TAKE1(GracefulShutdownTimeout, int ap_signal_server(int *, apr_pool_t *); void ap_mpm_rewrite_args(process_rec *); -extern apr_uint32_t ap_max_mem_free; +AP_DECLARE_DATA apr_uint32_t ap_max_mem_free; Shouldn't that be extern apr_uint32_t AP_DECLARE_DATA ap_max_mem_free; True, thanks. Fixed in r1179715. Modified: httpd/httpd/trunk/server/mpm_common.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm_common.c?rev=1179448r1=1179447r2=1179448view=diff == --- httpd/httpd/trunk/server/mpm_common.c (original) +++ httpd/httpd/trunk/server/mpm_common.c Wed Oct 5 21:25:58 2011 @@ -142,7 +142,7 @@ int ap_max_requests_per_child; char ap_coredump_dir[MAX_STRING_LEN]; int ap_coredumpdir_configured; int ap_graceful_shutdown_timeout; -apr_uint32_t ap_max_mem_free; +AP_DECLARE_DATA apr_uint32_t ap_max_mem_free; Shouldn't that be apr_uint32_t AP_DECLARE_DATA ap_max_mem_free; The other uses in server/*.c have the AP_DECLARE_DATA first, too. Probably both orders work.
Re: Caching - Generating E-Tags
Am 06.10.2011 19:03, schrieb Amila Liyanaarachchi: Hi Dev, I'm working on a caching protocol similar to HTTP on a different research. I have the following question regarding the e-tags. When does exactly apache computes the e-tag for a certain resource? Does it compute that when there is a request for that particular resource or is it computed by the server whenever a resource get modified in the server? request time because it normally contains the inode signature.asc Description: OpenPGP digital signature
Re: Change loglevel of File does not exist messages
On Thu, 6 Oct 2011, Jim Jagielski wrote: On Oct 5, 2011, at 7:07 PM, Daniel Ruggeri wrote: On 10/5/2011 4:18 PM, Stefan Fritsch wrote: True. But a generic apparatus for even more fine-grained log configuration won't happen in time for 2.4. I have toyed with the idea of this... do you have suggestions on how this might be implemented? I have thought about adding logging subsections for each module, which could then be configured separately (like core.client_error:crit ). But I then dropped the idea because it would involve lots of complexity that would then only be used by 2-3 modules. One of the ideas I heard (or thought of - don't recall) was to implement an error log filter such that messages matching a certain regex get dropped. To me that seems like it would be very expensive for busier sites, but would serve the purpose for some of the user base. It would be quite expensive to be sure… for some sites, logging is the most expensive part of the server. But regex matches are usually cheaper than logging to disk (especially considering the increasing number of CPU cores). So it may have some uses if a significant number of messages is filtered out.
Fine grained error logging overrides [Was: Change loglevel of File does not exist messages]
I've been giving this a bunch of thought, not to 'tune' the messages, but simply localize them. The tuning of messages would be a snap. My thought is to build two reference tables, the first of replacement messages hashed by source messages, and the second of replacement messages hashed by source message pointer. On startup, read an arbitrary localization file of source:replacement error strings (corresponding to the strings scattered throughout our sources). These obviously include any subst tokens, so the file permissions of such a localization file must be as strong as the httpd and module binaries themselves. To keep things simple, I'd suggest a trivial format of en: File %s not found. de: blank line Where each line consists of a language code, colon ':', and LWS which is followed by that language's error message. The next en: code or a blank line would terminate parsing for that specific message. We need to read only one pair of codes at startup, although it is conceivable to have different error logs using different languages. Extending the behavior to do this would be pretty trivial. On every error log invocation, we look up the second pointer-replacement message table, and if not found, proceed to search for the string in the first source-replacement table. If not found, we use the source string, either way add the entry for the pointer-replacement string hash. There is a reasonable penalty on the first lookup. A btree lookup would really help with the one time string lookup if the error tables grow quite large. Such a string pointer-replacement lookup could be extended to add various flags such as desired log level. I'll be looking at the cpp to work out extraction of the strings of all ap_log calls in our core and modules. Other thoughts?
Re: Fine grained error logging overrides [Was: Change loglevel of File does not exist messages]
On 10/6/2011 1:07 PM, William A. Rowe Jr. wrote: On startup, read an arbitrary localization file of source:replacement error strings (corresponding to the strings scattered throughout our sources). These obviously include any subst tokens, so the file permissions of such a localization file must be as strong as the httpd and module binaries themselves. To keep things simple, I'd suggest a trivial format of en: File %s not found. de: blank line [Packing these into a single file implies utf-8 formatting of our error text, irrespective of the formatting of the %s patterns. Can we live with that? If not, a per language table would be needed to make any sense of the contents of that file.]
Re: 2.0.65
On 10/6/2011 12:12 PM, Jim Jagielski wrote: On Oct 6, 2011, at 12:49 PM, William A. Rowe Jr. wrote: On 10/6/2011 8:08 AM, Jim Jagielski wrote: Would like to TR this week… we have 2 showstoppers awaiting just 1 vote each to be backport-able. And a third bug report at security@ (vulnerability is dubious, but it's still a bug ;-) Yeppers… Did you see my assessment and suggested fix? Yea, and I found a bunch of issues in trunk, but it doesn't appear that the offensive code exists in 2.2 and earlier. Still hacking on it. If we have consensus it isn't a vulnerability, we can move discussion here, but I want to make sure we get a bit of feedback on my assessment that it's not a security issue before I'd do that.
Re: CVE-2011-3192 in 2.0
Greetings, Any update to CVE-2011-3192 in 2.0? http://marc.info/?l=apache-httpd-devm=131548758430087 regards, Ryan
Re: CVE-2011-3192 in 2.0
On 10/6/2011 2:47 PM, Ryan Suarez wrote: Greetings, Any update to CVE-2011-3192 in 2.0? http://marc.info/?l=apache-httpd-devm=131548758430087 -- Is there a release schedule? no
Redundant new 2.3-beta feature?
I believe this patch, introducing SetEnvIf OID evaluation... http://svn.apache.org/viewvc?view=revisionrevision=220307 is rendered redundant, or at least should be redundant if the ap_expr engine can be made capable... by... http://svn.apache.org/viewvc?view=revisionrevision=1037137 Thoughts?
Re: Improving SSL config
On 06.10.2011 10:58, Rainer Jung wrote: On 02.10.2011 09:07, William A. Rowe Jr. wrote: -1 in this respect; faster is not more secure. We must default to setting the strictest cipher choices, with a commented-out this is faster, but far less secure alternative for those with less targeted assets. If someone is enabling mod_ssl, it is to secure their traffic, not to speed up their server. And no, MD4, although immune to *this* vector, is simply not preferable. Our current 2.2.x SSLCipherSuite contains e.g. SSLv2 and export ciphers. So there is a need to improve. My suggestion is a straight backport from trunk. So what is the strictest cipher choice you suggest? Assuming s/MD4/RC4/ in Bill's message, it seems that SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5 would be more appropriate for mod_ssl's default config. I agree that the current SSLCipherSuite default in 2.2.x should be improved (yes, right now it even includes suites with 40-bit encryption!), but giving specific precedence to RC4-SHA and AES128-SHA doesn't really feel right for a default config file. [1] Kaspar [1] in trunk, the SSLCipherSuite change in r966160 was inspired by http://journal.paul.querna.org/articles/2010/07/10/overclocking-mod_ssl/, which is basically favoring speed over cryptographic strength.
Re: Improving SSL config
On 10/7/2011 12:05 AM, Kaspar Brand wrote: On 06.10.2011 10:58, Rainer Jung wrote: On 02.10.2011 09:07, William A. Rowe Jr. wrote: -1 in this respect; faster is not more secure. We must default to setting the strictest cipher choices, with a commented-out this is faster, but far less secure alternative for those with less targeted assets. If someone is enabling mod_ssl, it is to secure their traffic, not to speed up their server. And no, MD4, although immune to *this* vector, is simply not preferable. Our current 2.2.x SSLCipherSuite contains e.g. SSLv2 and export ciphers. So there is a need to improve. My suggestion is a straight backport from trunk. So what is the strictest cipher choice you suggest? Assuming s/MD4/RC4/ in Bill's message, it seems that SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5 would be more appropriate for mod_ssl's default config. I agree that the current SSLCipherSuite default in 2.2.x should be improved (yes, right now it even includes suites with 40-bit encryption!), but giving specific precedence to RC4-SHA and AES128-SHA doesn't really feel right for a default config file. [1] Kaspar [1] in trunk, the SSLCipherSuite change in r966160 was inspired by http://journal.paul.querna.org/articles/2010/07/10/overclocking-mod_ssl/, which is basically favoring speed over cryptographic strength. Exactly... we should default to a server with a preference for cryptographic strength, but I have no objection to offering a commented-out, clearly documented 'alternative' configuration favoring performance, provided that is clearly labeled as 'not for sensitive data'.
