Re: [RELEASE CANDIDATE] libapreq 1.34-RC3
On Mon, 4 Jun 2007, Fred Moyer wrote: Issac Goldstand wrote: Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC3.tar.gz a try and report comments/problems/etc. to the apreq-dev list at [EMAIL PROTECTED] All tests OK on Fedora Core 5, perl 5.8.8, apache 1.3.37, mod_perl 1.30. +1 +1 All tests OK on Win32 (XP) - perl-5.8.8, apache-1.3.34 and mod_perl-1.29. -- best regards, Randy
AW: svn commit: r543511 - /httpd/httpd/branches/1.3.x/src/main/http_main.c
-Ursprüngliche Nachricht- Von: David McCreedy Gesendet: Dienstag, 5. Juni 2007 04:29 An: dev@httpd.apache.org Betreff: Re: svn commit: r543511 - /httpd/httpd/branches/1.3.x/src/main/http_main.c June 04, 2007 5:51 PM David McCreedy wrote: On 06/01/2007 05:42 PM, [EMAIL PROTECTED] wrote: I think I squashed those. Could you check out trunk and try another test? Thanks! It fixes the Bad pid error but I'm not sure all is well... On TPF we're not calling unset_pid_table on SIG_IDLE_KILLs. I'll have to track down why. I've figured out why some pids aren't being unset and I think it could affect other platforms besides TPF. They're hitting the else part of the if (child_slot = 0) statement in http_main.c's standalone_main function. I think the unset_pid_table call should be moved before this if. If we're in this section of code, don't we want to remove the pid from the table regardless of whether the slot is found in the scoreboard? Yes, we want to. Please have a look at r544218 (http://svn.apache.org/viewvc?view=revrevision=544218) Regards Rüdiger
Re: svn commit: r543511 - /httpd/httpd/branches/1.3.x/src/main/http_main.c
On Jun 4, 2007, at 10:29 PM, David McCreedy wrote: June 04, 2007 5:51 PM David McCreedy wrote: On 06/01/2007 05:42 PM, [EMAIL PROTECTED] wrote: I think I squashed those. Could you check out trunk and try another test? Thanks! It fixes the Bad pid error but I'm not sure all is well... On TPF we're not calling unset_pid_table on SIG_IDLE_KILLs. I'll have to track down why. I've figured out why some pids aren't being unset and I think it could affect other platforms besides TPF. They're hitting the else part of the if (child_slot = 0) statement in http_main.c's standalone_main function. I think the unset_pid_table call should be moved before this if. If we're in this section of code, don't we want to remove the pid from the table regardless of whether the slot is found in the scoreboard? Yes, in fact Rüdiger just committed a patch that does that.
Re: svn commit: r543511 - /httpd/httpd/branches/1.3.x/src/main/http_main.c
On June 05, 2007 1:45 AM Rüdiger wrote On June 04, 2007 5:51 PM David McCreedy wrote: I've figured out why some pids aren't being unset and I think it could affect other platforms besides TPF. They're hitting the else part of the if (child_slot = 0) statement in http_main.c's standalone_main function. I think the unset_pid_table call should be moved before this if. If we're in this section of code, don't we want to remove the pid from the table regardless of whether the slot is found in the scoreboard? Yes, we want to. Please have a look at r544218 (http://svn.apache.org/viewvc?view=revrevision=544218http://svn.apache.org/viewvc?view=revrevision=544218) Rüdiger Perfect. Thanks, -David - Original Message - From: Plümmailto:Plüm ; Rüdigermailto:Rüdiger ; VF-Groupmailto:[EMAIL PROTECTED] To: dev@httpd.apache.orgmailto:dev@httpd.apache.org Sent: Tuesday, June 05, 2007 1:45 AM Subject: AW: svn commit: r543511 - /httpd/httpd/branches/1.3.x/src/main/http_main.c -Ursprüngliche Nachricht- Von: David McCreedy Gesendet: Dienstag, 5. Juni 2007 04:29 An: dev@httpd.apache.orgmailto:dev@httpd.apache.org Betreff: Re: svn commit: r543511 - /httpd/httpd/branches/1.3.x/src/main/http_main.c June 04, 2007 5:51 PM David McCreedy wrote: On 06/01/2007 05:42 PM, [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: I think I squashed those. Could you check out trunk and try another test? Thanks! It fixes the Bad pid error but I'm not sure all is well... On TPF we're not calling unset_pid_table on SIG_IDLE_KILLs. I'll have to track down why. I've figured out why some pids aren't being unset and I think it could affect other platforms besides TPF. They're hitting the else part of the if (child_slot = 0) statement in http_main.c's standalone_main function. I think the unset_pid_table call should be moved before this if. If we're in this section of code, don't we want to remove the pid from the table regardless of whether the slot is found in the scoreboard? Yes, we want to. Please have a look at r544218 (http://svn.apache.org/viewvc?view=revrevision=544218http://svn.apache.org/viewvc?view=revrevision=544218) Regards Rüdiger
Re: make use of fs ACLs
Peter Somogyi wrote: Sorry, could you point there please? (I've already spent 4 hours for google and grep on trunk, asked expert people here but couldn't find anything.) Do you mean the hole is in the auth way (we can use mod_auth_pam instead), or in using fs ACLs instead of .htaccess? Twofold; if there was a code execution vulnerability somewhere within the in-process server stack, including scripting languages or running untrusted code, those files a visible to nobody. Essentially you are sharing the p/w list with everyone on the machine to crack the hashed passwords or search for their match. Secondly, unless ssl/tls is in use, the p/w's can be sniffed over the wire. If these are also your ssh login accounts... well, you can figure out the rest.
Apache 2.0.5x on Linux 64-bit
Hi, I need to clarify some of my doubts, How can I build Apache 2.0.5x source on Linux (64-bit) machine? Do I need to have a specific installer or I can use httpd-2.0.59.tar.gz only? On what all 64-bit platforms, Apache 2.0 or Apache 2.2 is supported? Please reply. Thanks, Renu CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS***
