Re: [VOTE] Release httpd-2.2.33

[Eric Covener]

On Tue, Jun 27, 2017 at 10:11 PM, William A Rowe Jr  wrote:
> I'd like to know that there is another binding vote before bothering to
> reroll. If the interest disappated faster than expected, that's fine.
> Assuming your request was an implicit intent to vote on the requested
> reroll.

I will be testing/voting, just a bit swamped.  No strong opinion on w/
or w/o the fix.

Re: [VOTE] Release httpd-2.2.33

[William A Rowe Jr]

I'd like to know that there is another binding vote before bothering to
reroll. If the interest disappated faster than expected, that's fine.
Assuming your request was an implicit intent to vote on the requested
reroll.

I thought this bug was more complex, but put all my other concerns aside,
we are looking pretty good according to the test framework. Looks like a
one line patch as described in the bugzilla ticket.

On Jun 27, 2017 12:44, "Jacob Champion"  wrote:

> On 06/27/2017 10:21 AM, William A Rowe Jr wrote:
>
>> If voters would rather that I address https://bz.apache.org/bugzilla
>> /show_bug.cgi?id=61220 and reroll, I'm fine with that.
>>
>
> I think that would be good, since we're planning to make this the Final
> Release.
>
> --Jacob
>

Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

[Eric Covener]

On Wed, Jun 21, 2017 at 2:00 PM, Jacob Champion  wrote:
> On 06/20/2017 02:19 PM, Jacob Champion wrote:
>>
>> Here's why I'm asking: if I were to propose the attached patch for
>> backport, what is the test case that *should* fail but doesn't?
>> (proxy_fcgi.t passes, no problem.) And once we get that test case, can we
>> show that it actually addresses a valid PHP-FPM use case, or is it a feature
>> without a user?
>
>
> Any thoughts on this?

I still cannot make any sense of what FPM is doing with our input.

I don't think either of the SCRIPT_NAME transformations make sense
just by the virtue of talking to FPM, primarily because it is neither
historically necessary or demonstrated as a problem.

if (fpm || apr_table_get(r->notes, "virtual_script")) {
   /*
* Adjust SCRIPT_NAME, PATH_INFO and PATH_TRANSLATED for PHP-FPM
* TODO: Right now, PATH_INFO and PATH_TRANSLATED look OK...
*/
   const char *pend;
   const char *script_name = apr_table_get(r->subprocess_env,
"SCRIPT_NAME");
   pend = script_name + strlen(script_name);
   if (r->path_info && *r->path_info) {
   pend = script_name + ap_find_path_info(script_name,
r->path_info) - 1;
   }
   while (pend != script_name && *pend != '/') {
   pend--;
   }
   apr_table_setn(r->subprocess_env, "SCRIPT_NAME", pend);
   ap_log_rerror(APLOG_MARK, APLOG_TRACE4, 0, r,
 "fpm:virtual_script: Modified SCRIPT_NAME to: %s",
 pend);
   }



I would just as well pull this block out entirely rather than taking
the "fpm||" half of the test out.  It seems like if you go out of your
way to run a script with PATH_INFO set as some parameter that we
shouldn't negate that.  And like the non path_info case, nobody has
ever asked us for this.

RE: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

[Moradhassel, Kavian]

Thanks!  That’s exactly the kind of ballpark I was hoping to hear. ☺


From: William A Rowe Jr [mailto:wr...@rowe-clan.net]
Sent: Tuesday, June 27, 2017 1:15 PM
To: httpd 
Subject: RE: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS



On Jun 27, 2017 12:08 PM, "Moradhassel, Kavian" 
> wrote:
Did this discussion result in a decision to provide a fix for the bug in 2.4.26 
and plan for a 2.4.27 soon?  I'm wondering if I should be waiting for a 2.4.27 
in the next handful of weeks, or if I should just accept that 2.4.26 has a bug 
that we need to work around...

We don't generally try to predict our release schedule, when it's baked we 
publish a release.

But Jim and Jacob are furiously updating the test framework as you were asking 
your question, so I'm guessing the group will be working to release this fix 
just as soon as it is agreed upon, within a week or few.

Re: [VOTE] Release httpd-2.2.33

[Jacob Champion]

On 06/27/2017 10:21 AM, William A Rowe Jr wrote:
If voters would rather that I address 
https://bz.apache.org/bugzilla/show_bug.cgi?id=61220 and reroll, I'm 
fine with that.


I think that would be good, since we're planning to make this the Final 
Release.


--Jacob

Re: [VOTE] Release httpd-2.2.33

[William A Rowe Jr]

On Jun 23, 2017 5:19 PM, "William A Rowe Jr"  wrote:

For your consideration... pre-release candidate tarballs of
Apache legacy httpd 2.2.33 can be found in;

http://httpd.apache.org/dev/dist/

Thanks all who merged the security work in and other fixes.
As we picked end of maintenance Jul 1 '17 - the [discuss]
thread had sufficient time for response - and none of the 2.4
regressions relate to what has been ported to 2.2... it looks
like this is 2.2's final hurrah...

Your votes, please?

+/-1
[ ] Release 2.2.33 as legacy GA


My own conditional +1.

If voters would rather that I address
https://bz.apache.org/bugzilla/show_bug.cgi?id=61220 and reroll, I'm fine
with that.

In any case, votes please. I'll declare the release aborted on the 30th and
the branch EOL on the 1st as originally agreed upon, in the absence of 3
binding reviews.

Re: [VOTE] Release httpd-2.2.33

[William A Rowe Jr]

Thanks Petr, every review and evaluation is appreciated!

On Jun 26, 2017 8:46 AM, "Petr Gajdos"  wrote:

On Fri, Jun 23, 2017 at 05:19:47PM -0500, William A Rowe Jr wrote:
> For your consideration... pre-release candidate tarballs of
> Apache legacy httpd 2.2.33 can be found in;
>
> http://httpd.apache.org/dev/dist/

Not sure if it is valuable info for you; I have run test suite and it
passes, see the attachement.

Petr

RE: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

[William A Rowe Jr]

On Jun 27, 2017 12:08 PM, "Moradhassel, Kavian"  wrote:

Did this discussion result in a decision to provide a fix for the bug in
2.4.26 and plan for a 2.4.27 soon?  I'm wondering if I should be waiting
for a 2.4.27 in the next handful of weeks, or if I should just accept that
2.4.26 has a bug that we need to work around...


We don't generally try to predict our release schedule, when it's baked we
publish a release.

But Jim and Jacob are furiously updating the test framework as you were
asking your question, so I'm guessing the group will be working to release
this fix just as soon as it is agreed upon, within a week or few.

Re: Anonymizing 403 responses [Was: svn commit: r1799731]

[William A Rowe Jr]

On Jun 27, 2017 3:00 AM, "Yann"  wrote:

On Tue, Jun 27, 2017 at 12:49 AM, William A Rowe Jr 
wrote:
> On Mon, Jun 26, 2017 at 5:43 PM, William A Rowe Jr 
wrote:
>> On Mon, Jun 26, 2017 at 5:34 PM, Yann  wrote:
>>
>>> What could be the "security blunders" with 404 vs 403?
>>
>> A 403 says "go away, you are denied". Hopefully modules are smart
>> about that.

It seems that one can create a "regular" file or directory containing
such "reserved" word (by using UNC paths, but I don't know enough
about Windows to say if it's really the case and from which version).
So we (or APR) should be able to determine whether it really exists or
not, and/or its access is truly denied by the OS (or httpd), and
return the correct 4xx no?


No. AIUI pervasive device names cannot be used as regular directory or
filenames at all.

It does exist. ./NULL on Windows is just as much a file as /dev/null is on
Unix.

APR does report this is a CHR file type/device.

The correct result has long been 403 forbidden on any OS.

Ignore Gregg's patch and go back to the underlying complaint. Rather than
forbidden, users are asking in a general scope for security by obscurity,
of advising the user agent that forbidden resources apparently don't exist.

As you pointed out this is not a great solution to bad admin practices.
But, the ask is there, so please ignore "on Windows" and let's consider
what is involved in adding support for a hard declaration of 404, or a late
transition from 403 to 404 (or any response code X to Y, for that matter.)

RE: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

[Moradhassel, Kavian]

Did this discussion result in a decision to provide a fix for the bug in 2.4.26 
and plan for a 2.4.27 soon?  I'm wondering if I should be waiting for a 2.4.27 
in the next handful of weeks, or if I should just accept that 2.4.26 has a bug 
that we need to work around...

Thanks!


-Original Message-
From: William A Rowe Jr [mailto:wr...@rowe-clan.net] 
Sent: Tuesday, June 20, 2017 1:00 PM
To: httpd 
Subject: Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

On Tue, Jun 20, 2017 at 11:17 AM, Jacob Champion  wrote:
> On 06/20/2017 09:16 AM, William A Rowe Jr wrote:
>>
>> It's released into the wild, what is done is done.
>
>
> Of course. But having it in the wild for three days is different than having
> it in the wild for six months.

Unless you are classifying this a security fix, it may prove to be
a less popular update given what we announced as fixed in 2.4.26.
The same isn't expected for 2.4.27, since some users prioritize
security updates and let others sit for a while, or undergo added
scrutiny for non-critical updates.

In any case, it will be in the wild for >3 days. It's at five days and
counting, if you tag and roll today. Vote is 72 hrs long, and we
always give our mirrors a day to catch up with us.

You must presume it is in the wild, and shortening the exposure
by a matter of days isn't significant. It just needs the appropriate
clear note in CHANGES with 2.4.27 so that users are prepared
for the change (or reversion).

Re: svn commit: r1800050 - in /httpd/test/framework/trunk: scripts/uds-test.pl t/modules/proxy.t

[Jacob Champion]

On 06/27/2017 04:39 AM, j...@apache.org wrote:

Author: jim
Date: Tue Jun 27 11:39:02 2017
New Revision: 1800050

URL: http://svn.apache.org/viewvc?rev=1800050=rev
Log:
Make this self-contained... Should really pull do_do_run_run
out :)

Removed:
 httpd/test/framework/trunk/scripts/uds-test.pl
Modified:
 httpd/test/framework/trunk/t/modules/proxy.t

Modified: httpd/test/framework/trunk/t/modules/proxy.t
URL: 
http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/modules/proxy.t?rev=1800050=1800049=1800050=diff
==
--- httpd/test/framework/trunk/t/modules/proxy.t (original)
+++ httpd/test/framework/trunk/t/modules/proxy.t Tue Jun 27 11:39:02 2017
@@ -5,6 +5,7 @@ use Apache::Test;
  use Apache::TestRequest;
  use Apache::TestUtil;
  use Apache::TestConfig ();
+require IO::Select;
  
  my $num_tests = 20;

  if (have_min_apache_version('2.4.7')) {
@@ -105,14 +106,56 @@ if (have_module('alias')) {
  skip "skipping tests without mod_alias" foreach (1..4);
  }
  
-if (have_min_apache_version('2.4.7')) {

-my $pid = fork;
-if ($pid) {
-system './scripts/uds-test.pl';
+sub uds_script
+{
+use Socket;
+use strict;
+
+my $socket_path = '/tmp/test-ptf.sock';
+unlink($socket_path);
+my $sock_addr = sockaddr_un($socket_path);
+socket(my $server, PF_UNIX, SOCK_STREAM, 0) || die "socket: $!";
+bind($server, $sock_addr) || die "bind: $!";
+listen($server,1024) || die "listen: $!";
+if (accept(my $new_sock, $server)) {
+my $data = <$new_sock>;
+print $new_sock "HTTP/1.0 200 OK\r\n";
+print $new_sock "Content-Type: text/html\r\n\r\n";
+print $new_sock "Hello 
World$data\n";
+close $new_sock;
+}
+unlink($socket_path);
+}
+
+sub do_do_run_run ($$)
+{
+my $msg = shift;
+my $func = shift;
+
+pipe(READ_END, WRITE_END);
+my $pid = fork();
+unless (defined $pid) {
+t_debug "couldn't fork $msg";
+ok 0;
+exit;
+}
+if ($pid == 0) {
+print WRITE_END 'x';
+close WRITE_END;
+$func->();
  exit;
  }
  # give time for the system call to take effect
-sleep 2;
+unless (IO::Select->new((\*READ_END,))->can_read(2)) {
+t_debug "timed out waiting for $msg";
+ok 0;
+kill 'TERM', $pid;
+exit;
+}
+}


Same problem here -- the signal back to the parent has to come after we 
call listen() in the child.


--Jacob

Re: svn commit: r1800066 - in /httpd/test/framework/trunk: Misc.pm t/modules/proxy_fcgi.t

[Jacob Champion]

On 06/27/2017 07:28 AM, j...@apache.org wrote:

Author: jim
Date: Tue Jun 27 14:28:50 2017
New Revision: 1800066

URL: http://svn.apache.org/viewvc?rev=1800066=rev
Log:
Re-use the runner sub function...

Modified:
 httpd/test/framework/trunk/Misc.pm
 httpd/test/framework/trunk/t/modules/proxy_fcgi.t

Modified: httpd/test/framework/trunk/Misc.pm
URL: 
http://svn.apache.org/viewvc/httpd/test/framework/trunk/Misc.pm?rev=1800066=1800065=1800066=diff
==
--- httpd/test/framework/trunk/Misc.pm (original)
+++ httpd/test/framework/trunk/Misc.pm Tue Jun 27 14:28:50 2017
@@ -28,7 +28,7 @@ BEGIN {
  # Just a bunch of useful subs
  }
  
-sub do_do_run_run ($$)

+sub do_do_run_run
  {
  my $msg = shift;
  my $func = shift;
@@ -43,7 +43,7 @@ sub do_do_run_run ($$)
  if ($pid == 0) {
  print WRITE_END 'x';
  close WRITE_END;
-$func->();
+$func->(@_);
  exit;
  }
  # give time for the system call to take effect
@@ -53,6 +53,7 @@ sub do_do_run_run ($$)
  kill 'TERM', $pid;
  exit;
  }
+return $pid;
  }
  
  


Modified: httpd/test/framework/trunk/t/modules/proxy_fcgi.t
URL: 
http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/modules/proxy_fcgi.t?rev=1800066=1800065=1800066=diff
==
--- httpd/test/framework/trunk/t/modules/proxy_fcgi.t (original)
+++ httpd/test/framework/trunk/t/modules/proxy_fcgi.t Tue Jun 27 14:28:50 2017
@@ -5,6 +5,8 @@ use Apache::Test;
  use Apache::TestRequest;
  use Apache::TestUtil;
  
+use Misc;

+
  my $have_fcgisetenvif= have_min_apache_version('2.4.26');
  my $have_fcgibackendtype = have_min_apache_version('2.4.26');
  
@@ -24,60 +26,32 @@ Apache::TestRequest::module("proxy_fcgi"
  
  # Launches a short-lived FCGI daemon that will handle exactly one request with

  # the given handler function. Returns the child PID; exits on failure.
-sub run_fcgi_handler($$)
+
+sub fcgi_request
  {
  my $fcgi_port= shift;
  my $handler_func = shift;
  
-# Use a pipe for ready-signalling between the child and parent. Much faster

-# (and more reliable) than just sleeping for a few seconds.
-pipe(READ_END, WRITE_END);
-my $pid = fork();
-
-unless (defined $pid) {
-t_debug "couldn't fork FCGI process";
-ok 0;
-exit;
-}
+# Child process. Open up a listening socket.
+my $sock = FCGI::OpenSocket(":$fcgi_port", 10);
  
-if ($pid == 0) {

-# Child process. Open up a listening socket.
-my $sock = FCGI::OpenSocket(":$fcgi_port", 10);
-
-# Signal the parent process that we're ready.
-print WRITE_END 'x';
-close WRITE_END;


This isn't an equivalent transformation. It's important that the socket 
is opened *before* signaling the parent; otherwise there's a race and 
the parent might try to ping the child before it's ready.


--Jacob

Re: Anonymizing 403 responses [Was: svn commit: r1799731]

[Yann]

On Tue, Jun 27, 2017 at 12:49 AM, William A Rowe Jr  wrote:
> On Mon, Jun 26, 2017 at 5:43 PM, William A Rowe Jr  
> wrote:
>> On Mon, Jun 26, 2017 at 5:34 PM, Yann  wrote:
>>
>>> What could be the "security blunders" with 404 vs 403?
>>
>> A 403 says "go away, you are denied". Hopefully modules are smart
>> about that.

Yes, and they can be smart about 404 too if that's the admin's choice.

>>
>> A 404 says "no such resource". Modules such as mod_speling try to
>> interpret what the user typed in an accommodating way, and come up
>> with something that aught to be served instead.
>>
>> In the particular example, /CON (device) might be interpreted as /.conf
>> (file). But if the admin/author is attentive, they deny access to .conf and
>> the remap attempt fails.

Provided /.conf access is granted, I don't see where the security
issue is (the user could request it directly). So either mod_speling
bypasses the access checks (I don't think it's the case) and that's
what I called its potential bug, or it's an "administrative" bug.

>
> FWIW mod_speling is well-understood to reveal such 'hidden files'.
> Even if we fixed the specific case for /con (device) remapping, all
> the user would have to do is attempt to access ".con" (no file found)
> to discover .conf in that directory, if it isn't prohibited.

For something like "/access/to/prn/sites", dunno if mod_speling is
pervert enough to notice the typo :p

>
> I trust that both presenting CHR files as 403 is not an issue, and that
> mod_speling's behavior is correct so far as it goes if users choose to
> deploy it. But it seems like there should be some deterministic way
> to reject non-file or other entities as not-found without other modules
> attempting to 'just fix it.'

I don't think the current behaviour is an issue, but it looks not
enough correct.
It seems that one can create a "regular" file or directory containing
such "reserved" word (by using UNC paths, but I don't know enough
about Windows to say if it's really the case and from which version).
So we (or APR) should be able to determine whether it really exists or
not, and/or its access is truly denied by the OS (or httpd), and
return the correct 4xx no?


Regards,
Yann.