Re: Crash while graceful restating a httpd installed at windows

[William A Rowe Jr]

On Aug 11, 2015 4:33 AM, "Christian Kütbach"  wrote:
>
> Hello,
>
> there is a bug (server crash), while graceful restart a httpd at windows:
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=58024
>
> Is there any progress?
>
> Can I help with testing or debugging, because I also would need a
solution to this crash?

Assistance is always welcome.

Ensure you have the .pdb files corresponding to the build you are running.

Toggle crash dump collection on windows.

Reproduce the crash.

Use windbg to open the newly created crash dump and collect a backtrace of
the crashed process and crashed thread.

Add this to the bug report, which will help the devs isolate what happened.

I expect this has everything to do with the fact that balancer members may
now be added during the running process.

Re: svn commit: r1694950 - in /httpd/httpd/trunk: include/http_request.h modules/http/http_request.c

[William A Rowe Jr]

On Mon, Aug 10, 2015 at 12:31 PM, Gregg Smith  wrote:

> Hi,
>
> I guess a minor at least.
>
> I did not add, remove or change the structure of the function, I simply
> made it available to modules. Does that warrant a major bump?
>

Never a major - that is reserved for changing the signature of functions
or members of structures that are catastrophic for previously compiled
modules.  This is not one of those :)

The previous absence of these exports was simply a bug, I don't see
a reason to bump the version minor for bug fixing.

If users were looking to determine compatibility, e.g. on the 2.4 released
branch, I might have another opinion, but during trunk development, we
fix it and move on.  A previously compiled module simply wouldn't have
any insight on these functions so correcting it doesn't break what they
were already aware of.

Re: Anyone have contacts at ohloh/openhub/blackduck?

[William A Rowe Jr]

On Thu, Jul 30, 2015 at 10:31 AM, Eric Covener  wrote:

> Anyone have a contact at ohloh/openhub/blackduck?  HTTP Server somehow
> lost all of its users (well, we have 1 user now), which takes us off
> the front page.
>

Hi Eric, no ownership/membership issues right now...

I think you are following the wrong project (its not 'httpd') or this has
more
to do with their site falling over? The app seems unresponsive.

https://www.openhub.net/p/apache

You are still a manager.

Re: Festina Lente - Nóirín Plunkett / Shirley

[William A Rowe Jr]

On Wed, Jul 29, 2015 at 2:05 PM, Jim Jagielski  wrote:

> If you have ever read the httpd doccos, there are many people who
> made them what they are, and are deserving of thanks. But today we
> have lost one of the main and core talents behind them.
>
> Nóirín was a bright light and a festive soul; they were talented
> and humble, with a passion tempered by joy and love. Their life
> had many highs, and some crushing lows, but Nóirín was always open
> and listened to their heart.
>
> I will miss Nóirín. We all will.


Indeed, we all do, thank you for your thoughtful words, Jim.

You can find our community's page memorializing Nóirín's life and
participation
and love for the at the ASF here;

www.apache.org/memorials/noirin.html

Re: CipherLists and who has control: aka what to do re: renegotiate - a simple way to set minimum levels in "core"?

[William A Rowe Jr]

This was addressed for 2.2.31 and 2.4.16... See the significantly revised
default docs/conf/extra/httpd-ssl.conf.in template for our recommended
config.

We won't be entertaining patches to change the compiled-in behavior in
these maintenance branches, this has severely negative impacts on users
updating to the same version major.minor for security updates on an
expedited basis.

Our discussions of compiled-in behavior changes is limited to svn trunk
(what will become httpd 2.6 or 3.0).

Much of this discussion becomes mute in the coming year or few as users
deploy OpenSSL, LibreSSL or GNUTLS with all legacy SSLv3 and TLSv1.0
support eliminated.
 On Jul 18, 2015 10:40, "Michael Felt"  wrote:

> A) OpenSSL and LibreSSL behave differently. Not surprising, because
> LibreSSL got it's start because OpenBSD was (my words) - fed up - with the
> upkeep of OpenSSL. And there are several presentations of "the first 30
> days of LibreSSL" where the focus was on cutting out anything they felt was
> inherently insecure (keeping calls for "linking", but having them be a
> no-op).
>
> B) Maybe for a long time - 'attackers' have been targeting weaknesses in
> the OpenSSL specification (e.g. arbitrary order decidedfor ciphers, kex,
> etc.). Since HeartBleed and POODLE there is, in any case, a lot more
> attention to these issues.
>
> My (humble) opinion: for something as important to society - as httpd is
> these days - httpd should do (and maybe you have already!) to make sure
> that "any client" cannot break a server, or force into low modes of
> encryption. "The server should decide" and the defaults should be higher
> than they are now - even if it be arranged by a "simple change" (I would
> hope) to httpd.conf where a configuration line is added to force "TLS1.2"
> as minimum encryption - should it be used.
>
> p.s. - my goal is to start a discussion - if this is not the right place -
> "kick me", and I shall look for a better venue.
>
> regards,
> Michael
>
> On 2015-07-18 3:44 PM, Eric Covener wrote:
>
>> On Sat, Jul 18, 2015 at 8:47 AM, Michael Felt  wrote:
>>
>>> * Should the server determine that for a specific "Location"/"Directory"
>>> more strict levels
>>> are needed then a new handshake (renegotiate if you prefer) for a
>>> stricter
>>> cipher should start. However, based on the assumption above (the
>>> strictest
>>> cipher that the client has is already being used) - this should always
>>> fail
>>> because the client is not already at that level.
>>>
>> The assumption is not right.  The servers list and the clients list
>> are in an arbitrary order decided by whoever wrote and configured the
>> software, and the server can choose to honor either (or neither, but
>> that would be weird) ordering.  Also, some ciphers do not have such a
>> strict relative ordering of strength.
>>
>
>

Re: Injecting HTTP request without using standard socket

[William A Rowe Jr]

I'd fork the event or worker MPM module.  Sadly, we have never decoupled
transport from the MPM model, but the solution would just work.
On Jul 17, 2015 16:25, "Phil Lello"  wrote:

> Hi all,
>
> I'm currently developing a pseudo-VPN service, and would like to be able
> to inject requests (and process responses) without going through the stock
> HTTP/HTTPS endpoints.
>
> Is this possible purely as a module, or would I need to have a custom
> HTTPD? I think this touches on the proxy enhancements which I believe are
> on this list.
>
> What I'm trying to achieve at the pseudo-VPN layer is server selection
> based on purely the first line of the HTTP request, or in the case of
> HTTPS, by picking a server from SNI. I want to prefix a small header
> (probably just the sockaddr struct) on requests coming out of the VPN, then
> send that plus the request payload on to apache. This will then be used to
> set the REMOTE_HOST. X-Forwarded-For isn't an option as I want to pass
> encrypted traffic on for processing by the normal httpd code.
>
> I am considering using one of UNIX-domain sockets, TCP/IP sockets, or an
> API binding to the VPN as the transport layer for requests, so want to
> inject packets/consume responses somewhere just after the normal apache
> listen, once the REMOTE_HOST has been decoded.
>
> Thanks for any pointers on this - I'm currently too buried in the VPN code
> to learn the HTTPD API at the moment, but want get an idea for if my
> current architecture can work the way I want - I'm also trying to avoid
> taking on more code maintenance that I need to.
>
> Phil
>

Re: Comparing LibreSSL and OpenSSL based on ApacheTest t/ssl results

[William A Rowe Jr]

On Fri, Jul 17, 2015 at 10:37 AM, Michael Felt  wrote:

> On 2015-07-17 5:34 PM, Yann Ylavic wrote:
>
>> On Fri, Jul 17, 2015 at 5:23 PM, Michael Felt  wrote:
>>
>>> On 2015-07-17 4:18 PM, Yann Ylavic wrote:
>>>
 $ /path/to/libressl/2.2.1/bin/openssl s_client -connect localhost:8532
 -state

  What else did you change in your configuration files - to get it to
>>> listen
>>> on port 8352? When I run the same commands I do not see any port
>>> activated
>>> (just a file added to netstat -tn output) and the client cannot connect.
>>>
>> I used the port defined for the SSL VirtualHost in
>> /path/to/httpd/framework/trunk/t/conf/ssl/ssl.conf (i.e. I ran httpd
>> directly with the configuration files generated by the framework).
>>
>> That port may be determined the first time the tests are run though,
>> so you probably have to look at this VirtualHost's definition in your
>> environment...
>>
>> Here I can see:
>>  
>>
> So, did you run
> /path/to/httpd -f `pwd`/t/conf/httpd.conf -X
>

Easier, invoke t/TEST -start

Re: Comparing LibreSSL and OpenSSL based on ApacheTest t/ssl results

[William A Rowe Jr]

On Fri, Jul 17, 2015 at 9:18 AM, Yann Ylavic  wrote:

>
> Attached are the logs from both httpd and s_client, where we can see
> that httpd somehow expects a client certificate during the
> renegotiation (without sending any certificate request...), while
> s_client obviously does not send anything like that (but its key
> exchange).
>
> I can't explain that... I'd need to debug.
> Does this ring someone's bell?
>

Sure.  AIUI, LibreSSL stripped out TLS renegotiation as an 'unsafe thing'.

Some of our tests demonstrate per-dir renegotiation for stricter SSL
ciphers or client certs in specific contexts, but this would not be
a supported feature under LibreSSL if I understood their scope changes
correctly.  The test is right, IMHO.

Bill

Re: Comparing LibreSSL and OpenSSL based on ApacheTest t/ssl results

[William A Rowe Jr]

On Thu, Jul 16, 2015 at 12:02 PM, Michael Felt  wrote:

> Here I have the output of just one test t/ssl/pr12355.t - and note the
> differences in the ssl_access_log - not just the error messages (I have
> removed all "debug" messages from the logs as they were "in the way".
>
> LibreSSL is version 2.2.0, OpenSSL is version 0.9.8m (yes I know very old,
> will test with latest patches later - I hope not relevant to here).
>
> So, please note: LibreSSL says access is:
> t/logs/ssl_request_log:[16/Jul/2015:11:47:12 +] 127.0.0.1 - - "POST
> /require-sha-cgi/perl_echo.pl HTTP/1.1" 403 237
> while OpenSSL says
> t/logs/ssl_request_log:[16/Jul/2015:11:32:35 +] 127.0.0.1 TLSv1 RC4-SHA
> "POST /require-sha-cgi/perl_echo.pl HTTP/1.1" 200 11
>
> My question: what can I do to understand why OpenSSL is adding TLSv1
> RC4-SHA while LibreSSL is "- -"
>
>
I'll take this one item.  Take a look into our implementation of
ssl_var_lookup_ssl
and particularly ssl_var_lookup_ssl_cipher.  I would expect LibreSSL isn't
providing
any meaningful data to represent.

[VOTE] [PASSES] Release 2.2.31 as GA?

[William A Rowe Jr]

With 4/5 of the 2.2.30 voters having re-reviewed 2.2.31, and the single
s/-1/+1/ based on this re-roll, I'm confident in calling this vote a
success,
and am pushing this release to the mirrors for announcement tomorrow.

Thanks all for all the reviews of both 2.2 candidates (and all of the 4 2.4
candidates!) that you were able to participate in, seemed unusually
difficult
to make it this far, but here we are at last.

Yours,

Bill

On Wed, Jul 15, 2015 at 11:44 AM, William A Rowe Jr 
wrote:

> The pre-release candidate tarballs of Apache httpd 2.2.31, can be found
> in;
>
> http://httpd.apache.org/dev/dist/
>
>   +/-1
>   [  ]  Release 2.2.31 GA (apr 1.5.2, apr-util 1.5.4)
>
> Win32 src to follow in an hour this round. With such an insignificant
> set of changes to a generally approved 2.2.30 which enjoyed the full
> 3-day voting period, I expect to end this vote tomorrow at 17:00GMT
> Thursday, if there are sufficient votes cast.
>
> The entire delta between 2.2.30 and 2.2.31 is attached, for your initial
> inspection.
>

Re: [VOTE] [24 hr] Release 2.2.31 as GA?

[William A Rowe Jr]

On Wed, Jul 15, 2015 at 11:44 AM, William A Rowe Jr 
wrote:

> The pre-release candidate tarballs of Apache httpd 2.2.31, can be found
> in;
>
> http://httpd.apache.org/dev/dist/
>
>   +/-1
>

  [+1]  Release 2.2.31 GA (apr 1.5.2, apr-util 1.5.4)

>
My own vote after preparing and exercising -win32-src.  The linux builds
have long looked good.

Re: The show goes on - 2.4.16

[William A Rowe Jr]

On Jul 16, 2015 8:04 AM, "Michael Felt"  wrote:
>
> First little thing I ran into - that I did not have with 2.4.12 is this:
>
> root@x065:[/data/prj/apache/httpd/test]/opt/httpd/sbin/apachectl start
> AH00534: httpd: Configuration error: More than one MPM loaded.

> root@x065:[/data/prj/apache/httpd/test]grep -i mpm /etc/httpd/httpd.conf
> LoadModule mpm_prefork_module libexec/mod_mpm_prefork.so
> LoadModule mpm_worker_module libexec/mod_mpm_worker.so
> # Server-pool management (MPM specific)
> #Include /etc/httpd/extra/httpd-mpm.conf
>
> p.s. I had done configure with:
>
>   $ ./configure --enable-layout=AIX --with-apr=/opt/bin/apr-1-config
--with-apr-util=/opt/bin/apu-1-config --enable-mpms-shared=all
--enable-mods-shared=all --disable-lua --enable-load-all-modules
--enable-maintainer-mode --with-ssl

Looks correct...

--enable-mpms-shared=all
Worked as instructed...

--enable-load-all-modules
Did just as you asked.

Not sure offhand if we can hack some mpm-specific module exception to the
later.

[VOTE] [24 hr] Release 2.2.31 as GA?

[William A Rowe Jr]

The pre-release candidate tarballs of Apache httpd 2.2.31, can be found in;

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

  +/-1
  [  ]  Release 2.2.31 GA (apr 1.5.2, apr-util 1.5.4)

Win32 src to follow in an hour this round. With such an insignificant
set of changes to a generally approved 2.2.30 which enjoyed the full
3-day voting period, I expect to end this vote tomorrow at 17:00GMT
Thursday, if there are sufficient votes cast.

The entire delta between 2.2.30 and 2.2.31 is attached, for your initial
inspection.


httpd-2.2.30-2.2.31.delta
Description: Binary data

Re: [VOTE WITHDRAWN] Release 2.2.30 as GA?

[William A Rowe Jr]

On Jul 14, 2015 10:16 AM, "Jeff Trawick"  wrote:
>
> Thanks/Sorry :(

Entirely my fault, I was in sync with progress to late last evening, and
skimmed the morning thread.  No objections to reworking the release,
although my schedule keeps getting interrupted.

Later this evening it will be ready for review.

Re: svn commit: r9814 - /release/httpd/

[William A Rowe Jr]

Hi Jim,

This commit breaks our website, since the mirror they are directed to may
or may not contain the current advertised 2.4.12 based on exactly when that
specific mirror rsync's.

Please hold off 24 hours before committing the svn rm side of the svn mv in
the future... so that mirrors still host the image that we are currently
advertising?  Thx,

Bill

On Tue, Jul 14, 2015 at 7:18 AM,  wrote:

> Author: jim
> Date: Tue Jul 14 12:18:02 2015
> New Revision: 9814
>
> Log:
> Push to mirrors
>
> Added:
> release/httpd/CHANGES_2.4.16
> release/httpd/httpd-2.4.16-deps.tar.bz2   (with props)
> release/httpd/httpd-2.4.16-deps.tar.bz2.asc   (with props)
> release/httpd/httpd-2.4.16-deps.tar.bz2.md5
> release/httpd/httpd-2.4.16-deps.tar.bz2.sha1
> release/httpd/httpd-2.4.16-deps.tar.gz   (with props)
> release/httpd/httpd-2.4.16-deps.tar.gz.asc   (with props)
> release/httpd/httpd-2.4.16-deps.tar.gz.md5
> release/httpd/httpd-2.4.16-deps.tar.gz.sha1
> release/httpd/httpd-2.4.16.tar.bz2   (with props)
> release/httpd/httpd-2.4.16.tar.bz2.asc   (with props)
> release/httpd/httpd-2.4.16.tar.bz2.md5
> release/httpd/httpd-2.4.16.tar.bz2.sha1
> release/httpd/httpd-2.4.16.tar.gz   (with props)
> release/httpd/httpd-2.4.16.tar.gz.asc   (with props)
> release/httpd/httpd-2.4.16.tar.gz.md5
> release/httpd/httpd-2.4.16.tar.gz.sha1
> Removed:
> release/httpd/CHANGES_2.4.12
> release/httpd/httpd-2.4.12-deps.tar.bz2
> release/httpd/httpd-2.4.12-deps.tar.bz2.asc
> release/httpd/httpd-2.4.12-deps.tar.bz2.md5
> release/httpd/httpd-2.4.12-deps.tar.bz2.sha1
> release/httpd/httpd-2.4.12-deps.tar.gz
> release/httpd/httpd-2.4.12-deps.tar.gz.asc
> release/httpd/httpd-2.4.12-deps.tar.gz.md5
> release/httpd/httpd-2.4.12-deps.tar.gz.sha1
> release/httpd/httpd-2.4.12.tar.bz2
> release/httpd/httpd-2.4.12.tar.bz2.asc
> release/httpd/httpd-2.4.12.tar.bz2.md5
> release/httpd/httpd-2.4.12.tar.bz2.sha1
> release/httpd/httpd-2.4.12.tar.gz
> release/httpd/httpd-2.4.12.tar.gz.asc
> release/httpd/httpd-2.4.12.tar.gz.md5
> release/httpd/httpd-2.4.12.tar.gz.sha1
> Modified:
> release/httpd/Announcement2.4.html
> release/httpd/Announcement2.4.txt
> release/httpd/CHANGES_2.4
>
> Modified: release/httpd/Announcement2.4.html
>
> ==
> --- release/httpd/Announcement2.4.html (original)
> +++ release/httpd/Announcement2.4.html Tue Jul 14 12:18:02 2015
> @@ -15,60 +15,59 @@
>  
>
>  
> -   Apache HTTP Server 2.4.12 Released
> +   Apache HTTP Server 2.4.16 Released
>  
>  
> The Apache Software Foundation and the Apache HTTP Server Project are
> pleased to http://www.apache.org/dist/httpd/Announcement2.4.html";>announce
> -   the release of version 2.4.12 of the Apache
> +   the release of version 2.4.16 of the Apache
> HTTP Server ("Apache").  This version of Apache is our latest GA
> release of the new generation 2.4.x branch of Apache HTTPD and
> represents fifteen years of
> innovation by the project, and is recommended over all previous
> releases. This
> release of Apache is principally a security, feature
> -   and bug fix release. NOTE: there was no release of 2.4.11.
> +   and bug fix release. NOTE: versions 2.4.13, 2.4.14 and 2.4.15 were not
> released.
>  
>  
> -http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3583
> ">CVE-2014-3583
> - mod_proxy_fcgi: Fix a potential crash due to buffer over-read, with
> - response headers' size above 8K.
> +http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3183
> ">CVE-2015-3183
> + core: Fix chunk header parsing defect.
> + Remove apr_brigade_flatten(), buffering and duplicated code from
> + the HTTP_IN filter, parse chunks in a single pass with zero copy.
> + Limit accepted chunk-size to 2^63-1 and be strict about chunk-ext
> + authorized characters.
>  
> -http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3581
> ">CVE-2014-3581
> - mod_cache: Avoid a crash when Content-Type has an empty value.
> - PR 56924.
> +http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3185
> ">CVE-2015-3185
> + Replacement of ap_some_auth_required (unusable in Apache httpd 2.4)
> + with new ap_some_authn_required and ap_force_authn hook.
>  
> -http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8109
> ">CVE-2014-8109
> - mod_lua: Fix handling of the Require line when a LuaAuthzProvider is
> - used in multiple Require directives with different arguments.
> - PR57204.
> +http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0253
> ">CVE-2015-0253
> + core: Fix a crash with ErrorDocument 400 pointing to a local URL-path
> + with the INCLUDES filter active, introduced in 2.4.11. PR 57531.
>  
> -http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5704
> ">CVE-201

[VOTE WITHDRAWN] Release 2.2.30 as GA?

[William A Rowe Jr]

On Tue, Jul 14, 2015 at 8:06 AM, William A Rowe Jr 
wrote:

> On Jul 11, 2015 10:29 AM, "William A Rowe Jr"  wrote:
>
> >
> > The pre-release candidate tarballs of Apache httpd 2.2.30, can be found
> in;
> >
> > http://httpd.apache.org/dev/dist/
>
>   [+1]  Release 2.2.30 GA (apr 1.5.2, apr-util 1.5.4)
>
>
> The PROXY_DECLARE bug doesn't seem to be a showstopper, the announce can
> make note of that fix.
>
>
I misread Jeff's vote this morning (my appologies), and \retract my +1
based on his concerns. I'm withdrawing this release from consideration (and
it had not yet traveled to mirrors)

I will prepare a single patch 2.2.31 based on this fix alone and resubmit
to the group later today for an expedited 24 hour release vote, given that
the delta is easily re-validated by existing reviewers..

Bill

Re: [VOTE] Release 2.2.30 as GA?

[William A Rowe Jr]

On Jul 11, 2015 10:29 AM, "William A Rowe Jr"  wrote:

>
> The pre-release candidate tarballs of Apache httpd 2.2.30, can be found
in;
>
> http://httpd.apache.org/dev/dist/

  [+1]  Release 2.2.30 GA (apr 1.5.2, apr-util 1.5.4)


The PROXY_DECLARE bug doesn't seem to be a showstopper, the announce can
make note of that fix.

With that issue addressed, this is my +1 for release.


Pushing to the mirrors ASAP.
Bill

Re: [VOTE] Release Apache httpd 2.4.16 as GA

[William A Rowe Jr]

On Jul 10, 2015 4:34 PM, "Jim Jagielski"  wrote:
>
> The pre-release test tarballs for Apache httpd 2.4.16 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'm calling a VOTE on releasing these as Apache httpd 2.4.16 GA.

[X] +1: Good to go

> Thx!
And thank you!

> PS: Hopefully, 4th time's the charm!
Indeed :)

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[William A Rowe Jr]

We can have a dialog about the best behavior of our default config.
However...

On Sat, Jul 11, 2015 at 9:56 AM, Kaspar Brand 
wrote:

> On 01.07.2015 14:27, Ben Laurie wrote:
> > On 1 November 2014 at 09:05, Kaspar Brand 
> wrote:
> >> The fundamental objection I have to enabling stapling by default in our
> >> GA releases is that it would enable a "phoning home" feature (to the
> >> CA's OCSP responders) as a side effect of configuring a certificate.
> >> This is a setting I consider unacceptable for software published by the
> >> Apache HTTP Server project - the default must be opt-in, not opt-out.
> >
> > I've just become aware of this objection and would like to understand
> > the thinking behind it. Firstly, it seems strange to call this
> > "phoning home", a term that _usually_ means connecting to the vendor
> > of the s/w.
> >
> > But more importantly, what harm is there in a server connecting to the
> > OCSP responders for the certificates it is serving? Why is this
> > "unacceptable"?
>
> It's unacceptable for at least two reasons: a) by default, an HTTP
> server is supposed to process *incoming* requests, not make accidental
> outgoing connections in addition (at least not unless it's explicitly
> instructed to do so); b) there's no statement in our license with an
> explicit caveat on such a side effect ("when relying on our default
> settings, configuring a site with an SSL server certificate may result
> in unsolicited outgoing HTTP requests" - and no, I do not want to see
> our license amended by things like that).
>

Our License says nothing about accepting requests, either.  Licenses
don't express these mechanics.  They define the terms for users to
"reproduce, prepare Derivative Works of, publicly display, publicly
perform,
sublicense, and distribute" the work and its derivatives, and the
corresponding
patent rights as well.

A number of ASF works are servers.  A number are clients.  A number are
both clients and servers.  OCSP is hardly an accidental request, any more
than
the proxy module requests.  And in forwarding requests to https proxy
servers,
(another side effect) verifying the OCSP identity of the connected server
is
hardly an unexpected side effect, it's a characteristic of the protocol
(that
backend *server* advertised OCSP validation - stapled or indirect, and that
the *user* configured the certificate for OCSP validation).  Third party
OCSP
validation is so problematic that OCSP stapling is a blindly obvious
enhancement
that will far offset the routing configuration issues it also inspires

So your premise above is, well, outright silly.


> I maintain my objection to uncommenting "#SSLUseStapling On" in our
> default config in httpd-ssl.conf.in - and for the record, also to
> changing code, be that in ssl_engine_config.c:modssl_ctx_init() or
> elsewhere. Those keen on enabling it by default on behalf of the users
> ("because we know what is good for you") are free to lobby with the OS
> vendors to have their package defaults changed.
>

You are welcome to object, and I think Ben's reply here to your thoughts
and observations, particularly your early one, since he is advocating for
this
change and this would move the dialog along to a conclusion.

Contrawise, httpd project can do the 'right thing' from our perspective,
and
the downstream distributors can correspondingly disable it.

Moreso, any enterprise so affected already is configuring httpd to their own
organization's standards and policies.

If you are suggesting we shouldn't change the compiled-in default, I can
agree, POLS (Principal Of Least Surprise).  If you are suggesting the
default
config shouldn't reflect the ability to efficiently handle OCSP by
stapling, here
I think we would disagree.

[VOTE] Release 2.2.30 as GA?

[William A Rowe Jr]

The pre-release candidate tarballs of Apache httpd 2.2.30, can be found in;

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

  +/-1
  [  ]  Release 2.2.30 GA (apr 1.5.2, apr-util 1.5.4)

Win32 src to follow shortly, vote to run through 14:30 GMT Tuesday.

Re: [NOTICE] Intent to T&R 2.4.16 next week

[William A Rowe Jr]

If you are hung up today, I'll go ahead and roll early this evening.  Looks
like zero churn for the past couple weeks, a bit of bug fixing and
diagnosis, so looking rock solid.
On Jul 9, 2015 8:16 AM, "Jim Jagielski"  wrote:

> Considering the amount of churn, I will T&R tomorrow am (Friday) to
> give 2.4 some time to settle and for people to test/review before
> we burn another tag :)
>
> > On Jul 8, 2015, at 8:58 PM, William A Rowe Jr 
> wrote:
> >
> > It appears that STATUS has been effectively resolved on both branches,
> nothing significant that doesn't alter APIs/Directives in a significant way
> is ignored, and we seem to be at a stable point for a T&R.  One nice patch
> from Eric could use a vote/backport, but it is anything but critical.
> >
> > Jim, please let us know if you plan to tag 2.4.16 Thursday morning?
> Otherwise, I'll proceed to T&R in the early afternoon as I T&R 2.2.30 as
> well.  With very sparse number of testers, I'm unwilling to wait for
> Friday, particularly since patch review has been particularly sparse in the
> community over the past month or few, and my own opportunity to review and
> vote on both candidates is limited by travel for a friend's wedding.
> Announcing these Monday - or Tuesday on the outside if there aren't
> sufficient votes over the weekend, seems like a good thing for our users.
> >
> > Bill
> >
>
>

Re: trunk/modules/http2 built and tested

[William A Rowe Jr]

You can do an

svn mkdir https://svn.apache.org/repos/asf/httpd/test/mod_h2
svn cp -r1690247 https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/
http2/sandbox  https://svn.apache.org/repos/asf/httpd/test/mod_h2/trunk

to shift that all over to the test tree, perhaps integrate into
test/framework/ a bit later on if it's possible.

On Fri, Jul 10, 2015 at 10:50 AM, Stefan Eissing <
stefan.eiss...@greenbytes.de> wrote:

>
> Am 10.07.2015 um 17:04 schrieb William A Rowe Jr :
>
> On Fri, Jul 10, 2015 at 6:57 AM, Stefan Eissing <
> stefan.eiss...@greenbytes.de> wrote:
>
>> FYI: just checked in a modules/http2 that takes part in the build
>> process, similar options as mod_ssl
>>
>>   --enable-h2
>>   --with-nghttp2=
>>
>> Tests were removed, so all sandbox/* is gone. Instead, I transformed my
>> git mod_h2 into a repository with just the test setup and cases. If
>> interested, you may find it here: https://github.com/icing/mod_h2_test
>
>
> There is a repository, http://svn.apache.org/repos/asf/httpd/test/ for
> all test
> resources that aren't part of the httpd tarballs/distribution.  It can
> certainly
> fit in a new mod_h2/trunk/ tree for the time being; if it were possible to
> integrate it into
> http://svn.apache.org/repos/asf/httpd/test/framework/trunk/
> that would be excellent, as this is the regression test many of us perform
> to initially validate potentially breaking changes.
>
> I expect the behavior of mod_h2 to degrades over time, absent tests to
> demonstrate correct behavior.
>
> I agree. I was not sure about the test thing and how it's used. That is
> why I put the tests in a githup repo for the time being.
>
> //Stefan
>

Re: trunk/modules/http2 built and tested

[William A Rowe Jr]

On Fri, Jul 10, 2015 at 6:57 AM, Stefan Eissing <
stefan.eiss...@greenbytes.de> wrote:

> FYI: just checked in a modules/http2 that takes part in the build
> process, similar options as mod_ssl
>
>   --enable-h2
>   --with-nghttp2=
>
> Tests were removed, so all sandbox/* is gone. Instead, I transformed my
> git mod_h2 into a repository with just the test setup and cases. If
> interested, you may find it here: https://github.com/icing/mod_h2_test


There is a repository, http://svn.apache.org/repos/asf/httpd/test/ for all
test
resources that aren't part of the httpd tarballs/distribution.  It can
certainly
fit in a new mod_h2/trunk/ tree for the time being; if it were possible to
integrate it into
http://svn.apache.org/repos/asf/httpd/test/framework/trunk/
that would be excellent, as this is the regression test many of us perform
to initially validate potentially breaking changes.

I expect the behavior of mod_h2 to degrades over time, absent tests to
demonstrate correct behavior.

Re: [NOTICE] Intent to T&R 2.4.16 next week

[William A Rowe Jr]

It appears that STATUS has been effectively resolved on both branches,
nothing significant that doesn't alter APIs/Directives in a significant way
is ignored, and we seem to be at a stable point for a T&R.  One nice patch
from Eric could use a vote/backport, but it is anything but critical.

Jim, please let us know if you plan to tag 2.4.16 Thursday morning?
Otherwise, I'll proceed to T&R in the early afternoon as I T&R 2.2.30 as
well.  With very sparse number of testers, I'm unwilling to wait for
Friday, particularly since patch review has been particularly sparse in the
community over the past month or few, and my own opportunity to review and
vote on both candidates is limited by travel for a friend's wedding.
Announcing these Monday - or Tuesday on the outside if there aren't
sufficient votes over the weekend, seems like a good thing for our users.

Bill

Re: Showstoppers

[William A Rowe Jr]

On Jul 8, 2015 6:59 AM, "Yann Ylavic"  wrote:
>
> However maybe the proposed backport about mod_reqtimeout (PR 56729) is
> worth being included too, but that's not a showstopper.
> It somehow made his way through 2.2.30 already (r1678698) but for
> 2.4.x this partial fix isn't enough (due to EOR handling).
> Would be nice if it could be reviewed on time (my only vote so far...).

Since it is a security related defect (not exploitable, ergo not a
vulnerability) I reviewed the 2.4 patch as well, thanks for pointing out
the discrepancy.

Re: now what?

[William A Rowe Jr]

My only hint, if you can structure the commits to single purposes (e.g.
relocate files, then a commit to merge new testcases, etc...) that is
helpful.  In particular - split code changes from the general reorg so it
is easier to follow, much as you can see we split committing xml docs
source changes from the commit after regenerating the resulting xhtml docs.

On Wed, Jul 8, 2015 at 9:42 AM, Stefan Eissing  wrote:

> Dear fellow committers,
>
> as some of you might already be aware, Jim and Eric punished my work on
> mod_h2 by checking in my code into httpd/trunk. And now they have given me
> committer access to clean up after them. Oh my.
>
> I have read gazillions of wiki pages designed for newbies like me to keep
> me from actually doing commits...
>
> But now I am almost ready. I have transformed the modules/http2 into
> something that compiles and runs my test cases here locally. I will
> tomorrow make some additional checks on my Ubuntu image and, should I not
> hear otherwise, commit the whole thing. I do not want to break anything. If
> you want me to to use a branch first, just let me know.
>
> Cheers,
>
> Stefan
>
> PS. Some data about me
>
> email: ic...@apache.org
> fullname: Stefan Eissing
> age: 49
> co-founder: greenbytes GmbH
> description: hired gun, casual gamer
> country+timezone: tschermany
> twitter: @icing
> http://www.eissing.org

Re: Showstoppers

[William A Rowe Jr]

2.4 still needs one reviewer to make the decision so we can have a 2.4, at
last.

Thanks to Mike for the review on the 2.2 showstopper, jumping ahead on
tarballs for 2.2.30 in the morning.

On Mon, Jul 6, 2015 at 10:38 AM, William A Rowe Jr 
wrote:

> Hope everyone enjoyed a nice weekend, and a good holiday for those here in
> the States!
>
> On 2.4, one significant issue remains unsettled...
>
>   *) mod_alias: Limit Redirect expressions to directory (Location) context
>  and redirect statuses (implicit or explicit).
>  trunk patch: http://svn.apache.org/r1686853
>   http://svn.apache.org/r1686856
>  2.4.x patch: trunk works (modulo CHANGES)
>  +1: ylavic, jim
>
>   *) Revert insufficiently thought-out mod_alias new expression feature
> http://svn.apache.org/viewvc?view=revision&revision=1663259
>  +1: wrowe, jim
>  [Mutually exclusive to multiple RedirectMatch patches proposed above,
>  but entirely possible to vote for both or vote against either.
>  [docs/manual .xml's require 'build all' regeneration]
>
> Graham, as an original author back in January, you are in the best
> position to review this fix for correctness.  Alternately, if someone is
> already reviewing that patch and can complete, we can avoid backing out
> this enhancement for a next attempt to T&R.  Backing it out is actually as
> simple as a veto of the backport, but framed the choice as a vote to be
> diplomatic.  I for one would support the backport once again after we've
> successfully released a 2.4.next.
>
> On 2.2, one significant issue remains unsettled...
>
>   *) http: follow up to r1686271 (trunk) => r1686271 (2.4.x)
>  Handle reentrance of state BODY_CHUNK_CR to avoid AH02901 when we eat
>  BWS from multiple reads, and limit number of chunk-BWS to 10.
>  trunk patch: http://svn.apache.org/r1688536
>   http://svn.apache.org/r1688538
>  2.2.x patch: trunk works
>  +1: ylavic, wrowe
>
> This one is a bit simpler to review, and mirrors what is already approved
> on 2.4 branch.
>
> I'm hoping to tag and roll 2.2 later this afternoon, and I recall Jim
> suggesting he's itching to T&R 2.4 early this week, so just more one pair
> of eyeballs could get us to that point.  If you can, my thanks to you in
> advance.
>
> Bill
>
>
>

Showstoppers

[William A Rowe Jr]

Hope everyone enjoyed a nice weekend, and a good holiday for those here in
the States!

On 2.4, one significant issue remains unsettled...

  *) mod_alias: Limit Redirect expressions to directory (Location) context
 and redirect statuses (implicit or explicit).
 trunk patch: http://svn.apache.org/r1686853
  http://svn.apache.org/r1686856
 2.4.x patch: trunk works (modulo CHANGES)
 +1: ylavic, jim

  *) Revert insufficiently thought-out mod_alias new expression feature
http://svn.apache.org/viewvc?view=revision&revision=1663259
 +1: wrowe, jim
 [Mutually exclusive to multiple RedirectMatch patches proposed above,
 but entirely possible to vote for both or vote against either.
 [docs/manual .xml's require 'build all' regeneration]

Graham, as an original author back in January, you are in the best position
to review this fix for correctness.  Alternately, if someone is already
reviewing that patch and can complete, we can avoid backing out this
enhancement for a next attempt to T&R.  Backing it out is actually as
simple as a veto of the backport, but framed the choice as a vote to be
diplomatic.  I for one would support the backport once again after we've
successfully released a 2.4.next.

On 2.2, one significant issue remains unsettled...

  *) http: follow up to r1686271 (trunk) => r1686271 (2.4.x)
 Handle reentrance of state BODY_CHUNK_CR to avoid AH02901 when we eat
 BWS from multiple reads, and limit number of chunk-BWS to 10.
 trunk patch: http://svn.apache.org/r1688536
  http://svn.apache.org/r1688538
 2.2.x patch: trunk works
 +1: ylavic, wrowe

This one is a bit simpler to review, and mirrors what is already approved
on 2.4 branch.

I'm hoping to tag and roll 2.2 later this afternoon, and I recall Jim
suggesting he's itching to T&R 2.4 early this week, so just more one pair
of eyeballs could get us to that point.  If you can, my thanks to you in
advance.

Bill

Re: svn commit: r1688474 [1/21] - in /httpd/httpd/trunk/modules/http2: ./ m4/ mod-h2.xcodeproj/ mod-h2.xcodeproj/project.xcworkspace/ mod-h2.xcodeproj/project.xcworkspace/xcshareddata/ mod-h2.xcodepro

[William A Rowe Jr]

On Jul 3, 2015 7:35 AM, "Jim Jagielski"  wrote:
>
>
> > On Jul 2, 2015, at 1:13 PM, William A Rowe Jr 
wrote:
> >
> > Just to clarify,
> >
> > On Tue, Jun 30, 2015 at 10:26 AM,  wrote:
> > Author: jim
> > Date: Tue Jun 30 15:26:16 2015
> > New Revision: 1688474
> >
> > URL: http://svn.apache.org/r1688474
> > Log:
> > Fold in git archive master of mod_h2 (latest commit 11905f474e)
> > from https://github.com/icing/mod_h2 as per software grant.
> >
> > You are following up to general@i.a.o with IP Clearance?
>
> Already done... it was done weeks ago w/ the Grant submitted to
> the sec and inc.

I know the SGA is done, thanks.  I was under the impression that an IP
Clearance statement/record is filed to general@i.a.o when that process is
complete.

As the VP Legal, you would know current process better than I :)

On Jul 3, 2015 4:20 AM, "Stefan Eissing" 
wrote:
>
> This needs general cleanup and the "sandbox/test" parts need to go into a
test setup, the rest of the sandbox will disappear. Basically,
modules/http2/mod_h2 will become the modules/http2 (or modules/h2 (pls!)),
some parts need to go into the acinclude.m4, others into docs.
>
> I am volunteering to do this, when I can...

Thanks!  Hopefully others here can help with the process.  Perhaps a wiki
page to document low hanging fruit?

Re: AW: [RFC] Enable OCSP Stapling by default in httpd trunk

[William A Rowe Jr]

On Jul 3, 2015 9:37 AM, "Rob Stradling"  wrote:
>
> On 03/07/15 11:13, Plüm, Rüdiger, Vodafone Group wrote:
> 
>
>> Thanks for the detailed explanation. So yes OCSP stapling is really
beneficial
>> if it is possible for the server admin to set it up. But it likely
requires additional
>> configuration steps outside of httpd to make the OCSP responder
reachable (like firewall clearances)
>> and leads to otherwise strange "slow" responses if this is not prepared.
>> Another obstacle with the current stapling code is that the connection
to the OCSP responder of the
>> CA needs to happen directly and cannot be done via a proxy.
>> Hence I agree with Kaspar that it should be off by default.
>
>
> Given the current stapling code, that's fair enough.
>
> Is it feasible to engineer around these issues so that stapling could be
enabled by default in some future httpd release?  If not, what's the
showstopper?

This was Ben's suggestion, top post.

At this project, the trunk of svn is the next major or minor version, e g
3.0 or 2.6 eventually, that would be after a 2.5 beta cycle to hash out the
kinks.

I'm strongly in favor of enabling this by default as a down-the-road
opportunity, and current concerns can be better addressed if everyone who
is touching that future 2.5.0+ version is looking at all issues that arise.

httpd 2.6/3.0 may well disable plaintext out-of-the-box, with a default tls
listener, sni named vhosts and http/2 enabled by default.  Ignoring
stapling due to enterprises that have no other reason to start supporting
ocsp and other modern validation and verification tools should not be a
primary goal, from the forward looking convention.

If it can't be solved with code, then it can always be changed back to
default of disabled before GA.

Re: svn commit: r1688474 [1/21] - in /httpd/httpd/trunk/modules/http2: ./ m4/ mod-h2.xcodeproj/ mod-h2.xcodeproj/project.xcworkspace/ mod-h2.xcodeproj/project.xcworkspace/xcshareddata/ mod-h2.xcodepro

[William A Rowe Jr]

Just to clarify,

On Tue, Jun 30, 2015 at 10:26 AM,  wrote:

> Author: jim
> Date: Tue Jun 30 15:26:16 2015
> New Revision: 1688474
>
> URL: http://svn.apache.org/r1688474
> Log:
> Fold in git archive master of mod_h2 (latest commit 11905f474e)
> from https://github.com/icing/mod_h2 as per software grant.
>

You are following up to general@i.a.o with IP Clearance?


> Since this is a git archive of master (for tracking and IP
> provenance history), it includes files that will likely
> be removed/renamed/etc...
>
> httpd/httpd/trunk/modules/http2/sandbox/httpd/packages/
>
> httpd/httpd/trunk/modules/http2/sandbox/httpd/packages/pcre-8.36.tar.gz
>  (with props)
>

We can blow this away immediately?  I thought we were out of the business
of trying to keep external packages up-to-date.

Bill

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[William A Rowe Jr]

On Wed, Jul 1, 2015 at 8:54 AM, Plüm, Rüdiger, Vodafone Group <
ruediger.pl...@vodafone.com> wrote:

>
> > -Ursprüngliche Nachricht-
> > Von: benlau...@gmail.com [mailto:benlau...@gmail.com] Im Auftrag von
> > Ben Laurie
> > Gesendet: Mittwoch, 1. Juli 2015 14:27
> > An: dev@httpd.apache.org
> > Betreff: Re: [RFC] Enable OCSP Stapling by default in httpd trunk
> >
> > On 1 November 2014 at 09:05, Kaspar Brand 
> > wrote:
> > > On 30.10.2014 15:51, Jeff Trawick wrote:
> > >> IMO the present concerns with OCSP Stapling are:
> > >>
> > >> * not so clear that it has seen enough real-world testing; commented
> > out
> > >> sample configs and better documentation will help, as will enabling
> > by
> > >> default in trunk (just a little?)
> > >> * related bugs 57121 and 57131
> > >>
> > >> A simple way to help with the broader issue raised in 57131, as well
> > as fix
> > >> 57121, is to not hold the global mutex while communicating with a
> > >> responder, with other handshakes completing with the existing
> > response in
> > >> the cache as long as it is valid, or with the appropriate
> > >> communication-error response otherwise (some details omitted ;) ).
> > >>
> > >> There are a few other bugs currently open for less severe issues.
> > >>
> > >> TIA for your comments!
> > >
> > > I'm -1 on this, under the assumption that 2.4.x would eventually also
> > > turn it on by default (yes, I'm aware of PR 50740, and CABF trying to
> > > push this).
> > >
> > > While enabling it by default on trunk probably doesn't change much
> > (in
> > > my experience, very, very few people really compile and run trunk, I
> > > would even claim that this applies to http devs, too), I feel that
> > the
> > > approach of "let's turn it on by default and see how many people run
> > > into problems" (and bring them up on httpd-users etc.) isn't right.
> > > Those interested in achieving a more widespread use should
> > specifically
> > > test OCSP stapling with mod_ssl, report their findings, file PRs on
> > > Bugzilla (and if possible, also submit suitable patches).
> > >
> > > The fundamental objection I have to enabling stapling by default in
> > our
> > > GA releases is that it would enable a "phoning home" feature (to the
> > > CA's OCSP responders) as a side effect of configuring a certificate.
> > > This is a setting I consider unacceptable for software published by
> > the
> > > Apache HTTP Server project - the default must be opt-in, not opt-out.
> >
> > I've just become aware of this objection and would like to understand
> > the thinking behind it. Firstly, it seems strange to call this
> > "phoning home", a term that _usually_ means connecting to the vendor
> > of the s/w.
> >
> > But more importantly, what harm is there in a server connecting to the
> > OCSP responders for the certificates it is serving? Why is this
> > "unacceptable"?
>
> Because in many organizations it can't because of network / firewall
> restrictions.
> If it tries nevertheless by default this causes the following issues with
> a default configuration:
>
> 1. As the network components / firewalls likely simply drop the packages
> the TCP connect to the OCSP server needs to run into TCP connection timeout
> which can take quite a while blocking the response back to the client of
> the webserver. Finding this out can be troublesome.
>
> 2. As the webserver will try to connect to the OCSP server quite often and
> is denied this likely triggers intrusion detection systems and starts all
> kind of security processes in an organization that thinks that a hacked
> server tries to connect to the outside world.
>

Although we are talking about large organizations... if they choose to
disable OCSP to their organization, isn't it equally upon them to configure
the server to ignore OCSP?

These are the same organization whose management are often those targeted
by malware anyways.  It's on them if they choose to ignore what few
security measures are available to the less savvy end user.

Re: [VOTE] Release Apache httpd 2.4.15 as GA

[William A Rowe Jr]

On Mon, Jun 22, 2015 at 2:01 PM, André Malo  wrote:

> * Yann Ylavic wrote:
>
> > It seems that RedirectMatch isn't documented without the third (URL)
> > argument, unless in .
>
> Huh? Actually it is (or maybe I'm not getting something here). I checked at
> least back until 2.0.
>
> http://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirect clearly
> documents this.
>

That's helpful, except that #redirectmatch does not point back to #redirect
as authoritative over arguments.  We all now agree that the 2.4.12 and prior
behavior should be preserved, but that doesn't remedy the documentation.

Re: svn commit: r1688339 - /httpd/httpd/trunk/modules/filters/mod_substitute.c

[William A Rowe Jr]

On Mon, Jun 29, 2015 at 9:44 PM, William A Rowe Jr 
wrote:

> You ALWAYS preserve unset state.  How else do you perform the THIRD merge?
>

To be more specific, httpd is allowed to merge whatever merges it likes.
If it wants
to optimize for the directory and then merge the base server to the merged
directory,
that's legit.  Overthinking the merge function yields worthless results for
any of the
possible optimization strategies.

Re: svn commit: r1688339 - /httpd/httpd/trunk/modules/filters/mod_substitute.c

[William A Rowe Jr]

You ALWAYS preserve unset state.  How else do you perform the THIRD merge?



On Mon, Jun 29, 2015 at 9:01 PM, Yann Ylavic  wrote:

> This won't work for eg, this second level inheritance: server context
> is on, vhost and inner Location are unset.
> Location->inherit_before will be unset whereas it should be on.
> We should not preserve the unset state IMHO.
>
> On Tue, Jun 30, 2015 at 3:27 AM,   wrote:
> > Author: wrowe
> > Date: Tue Jun 30 01:27:42 2015
> > New Revision: 1688339
> >
> > URL: http://svn.apache.org/r1688339
> > Log:
> > Very difficult to read, and therefore was wrong.
> >
> > Assert that the SubstituteInheritBefore option was explicitly toggled,
> > and do not default in 2.x to this legacy behavior.
> >
> >
> > Modified:
> > httpd/httpd/trunk/modules/filters/mod_substitute.c
> >
> > Modified: httpd/httpd/trunk/modules/filters/mod_substitute.c
> > URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_substitute.c?rev=1688339&r1=1688338&r2=1688339&view=diff
> >
> ==
> > --- httpd/httpd/trunk/modules/filters/mod_substitute.c (original)
> > +++ httpd/httpd/trunk/modules/filters/mod_substitute.c Tue Jun 30
> 01:27:42 2015
> > @@ -86,9 +86,16 @@ static void *merge_substitute_dcfg(apr_p
> >  subst_dir_conf *base = (subst_dir_conf *) basev;
> >  subst_dir_conf *over = (subst_dir_conf *) overv;
> >
> > -a->inherit_before = (over->inherit_before > 0 ||
> (over->inherit_before < 0 &&
> > -
> base->inherit_before > 0));
> > -if (a->inherit_before) {
> > +a->inherit_before = (over->inherit_before != -1)
> > +? over->inherit_before
> > +: base->inherit_before;
> > +/* SubstituteInheritBefore was the default behavior until 2.5.x,
> > + * and may be re-enabled as desired; this original default behavior
> > + * was to apply inherited subst patterns before locally scoped
> patterns.
> > + * In later 2.2 and 2.4 versions, SubstituteInheritBefore may be
> toggled
> > + * 'off' to follow the corrected/expected behavior, without
> violating POLS.
> > + */
> > +if (a->inherit_before == 1) {
> >  a->patterns = apr_array_append(p, base->patterns,
> >over->patterns);
> >  }
> >
> >
>

Re: svn commit: r1688339 - /httpd/httpd/trunk/modules/filters/mod_substitute.c

[William A Rowe Jr]

For 2.2/2.4 the delta is a one line change to trunk's behavior;

On Mon, Jun 29, 2015 at 8:27 PM,  wrote:

> Author: wrowe
> Date: Tue Jun 30 01:27:42 2015
> New Revision: 1688339
>
> URL: http://svn.apache.org/r1688339
> Log:
> Very difficult to read, and therefore was wrong.
>
> Assert that the SubstituteInheritBefore option was explicitly toggled,
> and do not default in 2.x to this legacy behavior.
>
>
> Modified:
> httpd/httpd/trunk/modules/filters/mod_substitute.c
>
> Modified: httpd/httpd/trunk/modules/filters/mod_substitute.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_substitute.c?rev=1688339&r1=1688338&r2=1688339&view=diff
>
> ==
> --- httpd/httpd/trunk/modules/filters/mod_substitute.c (original)
> +++ httpd/httpd/trunk/modules/filters/mod_substitute.c Tue Jun 30 01:27:42
> 2015
> @@ -86,9 +86,16 @@ static void *merge_substitute_dcfg(apr_p
>  subst_dir_conf *base = (subst_dir_conf *) basev;
>  subst_dir_conf *over = (subst_dir_conf *) overv;
>
> -a->inherit_before = (over->inherit_before > 0 ||
> (over->inherit_before < 0 &&
> -
> base->inherit_before > 0));
> -if (a->inherit_before) {
> +a->inherit_before = (over->inherit_before != -1)
> +? over->inherit_before
> +: base->inherit_before;
> +/* SubstituteInheritBefore was the default behavior until 2.5.x,
> + * and may be re-enabled as desired; this original default behavior
> + * was to apply inherited subst patterns before locally scoped
> patterns.
> + * In later 2.2 and 2.4 versions, SubstituteInheritBefore may be
> toggled
> + * 'off' to follow the corrected/expected behavior, without violating
> POLS.
> + */
> +if (a->inherit_before == 1) {
>

This becomes

if (a->inherit_before)

both the default case and explicitly toggled case will honor the legacy
2.2/2.4 behavior.
Explicitly toggling 'SubstitueInheritBefore off' will 'upgrade' to the
expected 2.5 behavior.

Re: svn commit: r1688331 - /httpd/httpd/trunk/modules/filters/mod_substitute.c

[William A Rowe Jr]

On Mon, Jun 29, 2015 at 8:06 PM, Yann Ylavic  wrote:

> Maybe defining (naming) inherit_before tristate values would help:
>

Not really...

+a->inherit_before = (over->inherit_before == INHERIT_ON
> + || (over->inherit_before == INHERIT_UNSET
> + && base->inherit_before == INHERIT_ON));
>  if (a->inherit_before) {
>

This logic was convoluted and therefore resulted in in the old default
behavior if the option wasn't explicitly set.  See the most recent trunk
commits for a more legible solution that follows the design pattern used
throughout other core modules.

Your logic above fails to preserve the unset state, and fails to when
consider base->inherit_before is explicitly off.  This is why it is
preferred not to invent new wheels when good wheels exist, particularly if
there will be a square side on the new wheel.

Bill

Re: svn commit: r1688331 - /httpd/httpd/trunk/modules/filters/mod_substitute.c

[William A Rowe Jr]

I was literally switching between a dead and live box repairing a corrupted
boot volume, so you may be right or I might have studied a stale patch.

Will refresh trunk in a few minutes here with suggested changes.
On Jun 29, 2015 7:42 PM, "Yann Ylavic"  wrote:

> On Tue, Jun 30, 2015 at 2:03 AM, William A Rowe Jr 
> wrote:
> > I can't approve this semantic mess.
> >
> > EITHER it is inherit_before on trunk-2.4-2.2 with a change of default
> > behavior, or it is inherit_after, again across all branches with a
> change of
> > default behavior.  The delta should consist of a one line difference,
> > evaluating inheritance behavior within the merge.
>
> Well, that's the case already, no?
> With 2.4.x patch applied:
>
> --- 2.4.x/modules/filters/mod_substitute.c  2015-06-30
> 01:52:18.595947091 +0200
> +++ trunk/modules/filters/mod_substitute.c  2015-06-30
> 01:41:18.027679427 +0200
> @@ -87,7 +87,7 @@
>  subst_dir_conf *over = (subst_dir_conf *) overv;
>
>  a->inherit_before = (over->inherit_before > 0 ||
> (over->inherit_before < 0 &&
> -
> base->inherit_before != 0));
> +
> base->inherit_before > 0));
>  if (a->inherit_before) {
>  a->patterns = apr_array_append(p, base->patterns,
>over->patterns);
>
> >
> > Please express your preference and I will offer several style fixes on
> trunk
> > that make this easier to follow, but we are not adding one directive to
> > trunk and a different one to 2.4 & 2.2 :-/
>
> Same directive in trunk and 2.[24] branches, default only changes, I
> don't see what you mean.
> This proposal allows to merge the inherit_before flag itself, that may
> be confusing / not suitable / overkill (dunno), so feel free to
> implement simpler/better code (the default merge-base-before-over
> semantic must be preserved for the branches, though).
>

Re: svn commit: r1688331 - /httpd/httpd/trunk/modules/filters/mod_substitute.c

[William A Rowe Jr]

I can't approve this semantic mess.

EITHER it is inherit_before on trunk-2.4-2.2 with a change of default
behavior, or it is inherit_after, again across all branches with a change
of default behavior.  The delta should consist of a one line difference,
evaluating inheritance behavior within the merge.

Please express your preference and I will offer several style fixes on
trunk that make this easier to follow, but we are not adding one directive
to trunk and a different one to 2.4 & 2.2 :-/
On Jun 29, 2015 6:44 PM,  wrote:

> Author: ylavic
> Date: Mon Jun 29 23:44:28 2015
> New Revision: 1688331
>
> URL: http://svn.apache.org/r1688331
> Log:
> mod_substitute: follow up to r1687680.
> Fix dir config merger 'over'-write, thanks Bill (again).
>
> Modified:
> httpd/httpd/trunk/modules/filters/mod_substitute.c
>
> Modified: httpd/httpd/trunk/modules/filters/mod_substitute.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_substitute.c?rev=1688331&r1=1688330&r2=1688331&view=diff
>
> ==
> --- httpd/httpd/trunk/modules/filters/mod_substitute.c (original)
> +++ httpd/httpd/trunk/modules/filters/mod_substitute.c Mon Jun 29 23:44:28
> 2015
> @@ -86,10 +86,9 @@ static void *merge_substitute_dcfg(apr_p
>  subst_dir_conf *base = (subst_dir_conf *) basev;
>  subst_dir_conf *over = (subst_dir_conf *) overv;
>
> -if (over->inherit_before < 0) {
> -over->inherit_before = (base->inherit_before > 0);
> -}
> -if (over->inherit_before) {
> +a->inherit_before = (over->inherit_before > 0 ||
> (over->inherit_before < 0 &&
> +
> base->inherit_before > 0));
> +if (a->inherit_before) {
>  a->patterns = apr_array_append(p, base->patterns,
>over->patterns);
>  }
>
>
>

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

[William A Rowe Jr]

Just a quick observation on the patch, you know you can use a tristate to
avoid an int?

Simply set the value to 2 in the config-create (the enum being off=0, on=1,
unset=2), check for RHS 'unset' during the merge, and in the feature toggle
test, explicitly check test for == of the non-default value.

And a style nit, we explicitly put in the variable type for each member,
and don't carry the type from member to member in the project's
structs/enums.



On Thu, Jun 25, 2015 at 10:47 AM,  wrote:

> Author: ylavic
> Date: Thu Jun 25 15:47:39 2015
> New Revision: 1687564
>
> URL: http://svn.apache.org/r1687564
> Log:
> Update mod_substitute proposal with SubstituteInheritBefore.
>
> Modified:
> httpd/httpd/branches/2.4.x/STATUS
>
> Modified: httpd/httpd/branches/2.4.x/STATUS
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1687564&r1=1687563&r2=1687564&view=diff
>
> ==
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Thu Jun 25 15:47:39 2015
> @@ -201,10 +201,17 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>   ints added at the end of core_server_config, the proposed
> merge
>   does a minor bump only.
>
> -  *) mod_substitute: Fix configuraton merge order. PR 57641
> +  *) mod_substitute: Configure patterns merge order. PR 57641
>   trunk patch: http://svn.apache.org/r1684900
> - 2.4.x patch: trunk works (modulo CHANGES)
> - +1: ylavic, minfrin
> +  http://svn.apache.org/r1687539
> + 2.4.x patch:
> http://people.apache.org/~ylavic/httpd-2.4.x-SubstituteInheritBefore.patch
> + +1: ylavic
> + ylavic: added r1687539 and discarded minfrin's vote (we must preserve
> + the current behaviour).  SubstituteInheritBefore allows to
> + configure the merge order; the default is Off in trunk
> (2.5+),
> + but still On in 2.4.x thanks to the changes in the backport
> patch
> + only (dcfg->inherit_before = 1 by default, and the doc is
> updated
> + accordingly).
>
>*) core: Avoid a possible truncation of the faulty header included in
> the
>   HTML response when LimitRequestFieldSize is reached.
>
>
>

Re: Last call... STATUS needing one sec fix vote [was Re: Roll 2.2.30]

[William A Rowe Jr]

On Fri, Jun 19, 2015 at 11:42 AM, William A Rowe Jr 
wrote:

>
> On Jun 18, 2015 1:45 PM, "William A Rowe Jr"  wrote:
> >
> > On Jun 11, 2015 8:22 AM, "Eric Covener"  wrote:
> > >
> > > On Thu, Jun 11, 2015 at 9:08 AM William A Rowe Jr 
> wrote:
> > >>
> > >> But withholding a security fix for legacy server users?  Sounds like
> a way to earn distrust of the user community, not reassure them that 2.4.14
> is the best version available.
> > >
> > > +1
> >
> > The 2.2 patches are in alignment with the resolved 2.4 security patches
> plus relaxed trailing spaces rule. Yann and I have reviewed, still weeks
> later 2.2.30 needs one more pair of eyeballs and a third +1 of the 2
> patches.
> >
> > I can T&R in the morning Friday if it has been reviewed, else it will be
> a while before I can RM.
>
> If there is a vote in the next 90 minutes, I'll proceed, otherwise I can
> proceed sometime next week after missing +1 is cast.
>
Just as a reminder, 2.2 STATUS contains;

  *) SECURITY: CVE-2015-3183 (cve.mitre.org)
 core: Fix chunk header parsing defect.
 Remove apr_brigade_flatten(), buffering and duplicated code from
 the HTTP_IN filter, parse chunks in a single pass with zero copy.
 Limit accepted chunk-size to 2^63-1 and be strict about chunk-ext
 authorized characters.  [Graham Leggett, Yann Ylavic]
  Submitted by: minfrin, ylavic
  Reviewed by: ylavic, wrowe,
  Backports: 1484852, 1684513
  Reported by: regilero 

  trunk
http://svn.apache.org/r1484852
http://svn.apache.org/r1684513
  2.4.x branch
http://svn.apache.org/r1684515
  2.2.x branch
http://people.apache.org/~wrowe/httpd-2.2.x-ap_http_filter-chunked-v6.patch
  +1: ylavic, wrowe
  jim notes: test framework errors due to 413->400 error change [test adjusted]
  wrowe notes: r1684513 was not neglected in this patch, already included

  *) core: Allow spaces after chunk-size for compatibility with implementations
 using a pre-filled buffer.
 trunk patch: http://svn.apache.org/r1685345
  http://svn.apache.org/r1685347
  http://svn.apache.org/r1685349
  http://svn.apache.org/r1685350
 2.[24].x patch:
http://people.apache.org/~ylavic/httpd-2.4.x-ap_http_filter_chunked-v3.patch
 (trunk works but CHANGES entry in the above patch is
  better since the APLOG_INFO part is already included
  in the CVE-2015-3183 patch)
 +1: ylavic, wrowe
 ylavic: CVE-2015-3183 patch httpd-2.2.x-ap_http_filter-chunked-v6.patch
 above must be applied first.


and has lingered now for two weeks (a month, actually, when measuring
secur...@httpd.apache.org time).  This blocks not only tagging 2.2, but
also publishing security guidance with corresponding patches for general
consumption, barring a successful release including these patches for 2.4
and 2.2.

If you had offered to review security patches in Jeff's 2.2 interest thread
of a month ago, please consider taking a bit of time to compare this change
to the corresponding change already approved in 2.4.x branch (and rather
extensively reviewed over the past two release votes).

Re: mod_session_crypto crash

[William A Rowe Jr]

If asking about crash-bugs on dev@, could you please include the backtrace?
 .pdb symbols make it useful, while
https://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx
shows how to load the user.dmp file and produce that backtrace.

User in that link seems to be changing too many things to make this a
useful problem report.  Hopefully you are familiar with looking in the
windows event log when "windows error is triggered before anything appears
in the apache log".  Or try running command-line, not as-a-service. to get
a console error.


On Wed, Jun 24, 2015 at 9:52 AM, Steffen  wrote:

>
> When build on Windows with no openssl or nss driver , I was assuming that
> mod_session crypto would use apr-crypto.
>
> Seems I was wrong,  then Apache crashes without anything in the log, quite
> some reports, see the latest at
> http://www.apachelounge.com/viewtopic.php?p=30892#30892
>
> When I build with the openssl driver , then all is fine.
>
>
>
>

Re: module configs across (pseudo) connections

[William A Rowe Jr]

On Jun 24, 2015 8:39 AM, "Eric Covener"  wrote:
>
> On Wed, Jun 24, 2015 at 9:26 AM, Graham Leggett  wrote:
> > I believe we should be treating the “pseudo” connections as real
connections, and perhaps by linking a “subconnection” to a “connection”
(c->main) in the same way we currently link a subrequest to a request
(r->main).
>
> There are some basics for this in trunk from jim. I think if the slave
> connections had their own bucket_alloc it might remove some of the
> copying in h2.

This will be the best-case solution. Even 'connection-level' filters could
be applied before 'network transport' filters are invoked.

This would have simplified mod_ftp data channel connection mechanics as
well.

Re: [VOTE] Release Apache httpd 2.4.15 as GA

[William A Rowe Jr]

You are correct, however the "syntax" never illustrated this.

It seems we need two syntaxes, not a [target] optional argument.
On Jun 22, 2015 2:02 PM, "André Malo"  wrote:

> * Yann Ylavic wrote:
>
> > It seems that RedirectMatch isn't documented without the third (URL)
> > argument, unless in .
>
> Huh? Actually it is (or maybe I'm not getting something here). I checked at
> least back until 2.0.
>
> http://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirect clearly
> documents this.
>
> """
> Other status codes can be returned by giving the numeric status code as the
> value of status. If the status is between 300 and 399, the URL argument
> must be present. If the status is not between 300 and 399, the URL argument
> must be omitted.
> """
>
> http://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirectmatch refers
> to
> the above ("This directive is equivalent to Redirect").
>
> nd
> --
> "Solides und umfangreiches Buch"
>   -- aus einer Rezension
>
> 
>

Re: [VOTE] Release Apache httpd 2.4.15 as GA

[William A Rowe Jr]

A sort of unusual case though, first fix is a docs patch, then a test case
for the newly-documented 16 year old behavior :) +1 to the collected
feedback and plan.
On Jun 22, 2015 9:32 AM, "Jim Jagielski"  wrote:

> Agreed. We should also, everytime we catch something like this,
> add a test-case to the perl test framework to ensure we don't trip
> over it again :)
>
> > On Jun 22, 2015, at 8:24 AM, Rainer Jung 
> wrote:
> >
> > Am 22.06.2015 um 14:04 schrieb Jeff Trawick:
> >> On Mon, Jun 22, 2015 at 8:02 AM, Jim Jagielski  >> > wrote:
> >>
> >>Seems that 3rd time was NOT the charm.
> >>
> >>Due to the regression I am canceling this VOTE.
> >>
> >>Let's patch 2.4.16-dev ASAP to handle this and I will T&R 2.4.16
> >>forthwith.
> >>
> >>
> >> Thanks, Jim!  We'll get through this eventually :)
> >>
> >> (And thanks Steffen and Reindl too!)
> >
> > +1 to both statements.
> >
> > My test went threw nicely, but due to the problem with the RedirectMatch
> I would have also voted -1.
> >
> > It is good we have those additional testers in the loop.
> >
> > Thanks
> >
> > Rainer
> >
>
>

Re: [VOTE] Release Apache httpd 2.4.15 as GA

[William A Rowe Jr]

On Sun, Jun 21, 2015 at 2:11 PM, Reindl Harald 
wrote:

>
> Am 21.06.2015 um 21:02 schrieb Yann Ylavic:
>
>> It seems that RedirectMatch isn't documented without the third (URL)
>> argument, unless in .
>>
>
All the way back to 1.3... the fact that it worked at all was a coincidence.

If this were an 'undocumented feature', then users are responsible for
submitting
a docs patch that it is a feature in-use.  We can't possibly predict every
broken-
but-otherwise-working configuration in existence.


> And [1] broke your configuration, assuming "^\/something\/$" is an
>> expression (not a regex).
>>
>> [1] http://svn.apache.org/r1663259
>>
>
> that may be true but
>
> * it is a regression breaking configs working like a
>   charm over years and IMHO a no-go for a minor update
>

That's called a charmed existence, and charms turn.  IMHO, it is a go (for
a subversion update, actually, minor would be 2.6.0, for example).


> * at makes little sense to provide a URL when you just
>   want the default 404 error page defined with
>   ErrorDocument  404 "html content" because by enforce
>   providing a URL the configuration is no longer re-useable
>   on different machines
>

Irrelevant.

Pulling Coar/Bowen '04 "Apache Cookbook" off the shelf, this error was
propagated by the last example in 5.8 (and likely elsewhere);

  Redirect gone /foo.html

which likely isn't working in 2.4.15.

As this is not a regression from 2.4.13 or 2.4.14 candidates, it seems to
me we should ship.

Re: [VOTE] Release Apache httpd 2.4.15 as GA

[William A Rowe Jr]

Reindl,

Try reverting http://svn.apache.org/viewvc?view=revision&revision=1663259
and see if this resolves your observed defect.
On Jun 21, 2015 12:53 PM, "Reindl Harald"  wrote:

> in fact RedirectMatch is *completly* broken
>
> RedirectMatch 404 ^\/something\/$
>
> and *any* URI get a 404 response not just with the long list from my
> previous post
>
> Am 21.06.2015 um 18:57 schrieb Reindl Harald:
>
>> -1
>>
>> just rebuilt my httpd rpm with the
>> http://httpd.apache.org/dev/dist/httpd-2.4.15.tar.bz2 on my testserver
>> and all vhosts are coming with a 404 page and nothing in the errorlog
>>
>> first i thought it's a https problem cause by a self signed wildcard
>> certificate, but the same after remove the mod_rewrite redirction
>> 
>>
>> "LogLevel debug core:debug" is not much helpful with only 1 line for
>> each request
>>
>> [Sun Jun 21 18:50:46.972582 2015] [headers:debug] [pid 25479]
>> mod_headers.c(899): AH01503: headers: ap_headers_error_filter()
>> 
>>
>> it is in fact that configuration file which suddenly triggers at *every*
>> request instead just mask several unwanted software even if it would
>> exist on the machine
>>
>> [root@testserver:~]$ cat conf/httpd-deny.conf
>> 
>>   AllowOverride   None
>>   Options None
>>   Require all denied
>> 
>> 
>>   Require all denied
>> 
>> RedirectMatch 404 ^/.*\.svn/(.*)$
>> RedirectMatch 404 ^/.*CVS/(.*)$
>> RedirectMatch 404 ^/.*\.asax$
>> RedirectMatch 404 ^/.*\.ascx$
>> RedirectMatch 404 ^/.*\.ashx$
>> RedirectMatch 404 ^/.*\.asmx$
>> RedirectMatch 404 ^/.*\.asp$
>> RedirectMatch 404 ^/.*\.aspx$
>> RedirectMatch 404 ^/.*\.axd$
>> RedirectMatch 404 ^/.*\.back$
>> RedirectMatch 404 ^/.*\.bak$
>> RedirectMatch 404 ^/.*\.bat$
>> RedirectMatch 404 ^/.*\.cfm$
>> RedirectMatch 404 ^/.*\.cmd$
>> RedirectMatch 404 ^/.*\.csproj$
>> RedirectMatch 404 ^/.*\.dll$
>> RedirectMatch 404 ^/.*\.DS_Store$
>> RedirectMatch 404 ^/.*\.exe$
>> RedirectMatch 404 ^/.*\.FBCIndex$
>> RedirectMatch 404 ^/.*\.ini$
>> RedirectMatch 404 ^/.*\.jhtml$
>> RedirectMatch 404 ^/.*\.jsp$
>> RedirectMatch 404 ^/.*\.log$
>> RedirectMatch 404 ^/.*\.mdf$
>> RedirectMatch 404 ^/.*\.ocx$
>> RedirectMatch 404 ^/.*\.py$
>> RedirectMatch 404 ^/.*\.rb$
>> RedirectMatch 404 ^/.*\.sh$
>> RedirectMatch 404 ^/.*\.sql$
>> RedirectMatch 404 ^/.*\.vbproj$
>> RedirectMatch 404 ^/.*\.webinfo$
>> RedirectMatch 404 ^/.*admin-bak/(.*)$
>> RedirectMatch 404 ^/.*~admin/(.*)$
>> RedirectMatch 404 ^/.*backups/(.*)$
>> RedirectMatch 404 ^/.*backup/(.*)$
>> RedirectMatch 404 ^/.*_backup/(.*)$
>> RedirectMatch 404 ^/.*bak/(.*)$
>> RedirectMatch 404 ^/.*_errors/(.*)$
>> RedirectMatch 404 ^/.*htbin/(.*)$
>> RedirectMatch 404 ^/.*iisadmin/(.*)$
>> RedirectMatch 404 ^/.*iisprotect/(.*)$
>> RedirectMatch 404 ^/.*iissamples/(.*)$
>> RedirectMatch 404 ^/.*incoming/(.*)$
>> RedirectMatch 404 ^/.*Install/(.*)$
>> RedirectMatch 404 ^/.*logs/(.*)$
>> RedirectMatch 404 ^/.*Log/(.*)$
>> RedirectMatch 404 ^/.*LOG/(.*)$
>> RedirectMatch 404 ^/.*lost\+found/(.*)$
>> RedirectMatch 404 ^/.*oldfiles/(.*)$
>> RedirectMatch 404 ^/.*_passwords/(.*)$
>> RedirectMatch 404 ^/.*_private/(.*)$
>> RedirectMatch 404 ^/.*sslkeys/(.*)$
>> RedirectMatch 404 ^/.*sysbackup/(.*)$
>> RedirectMatch 404 ^/.*sysbackup/(.*)$
>> RedirectMatch 404 ^/.*temp/(.*)$
>> RedirectMatch 404 ^/.*_vti_bin/(.*)$
>> RedirectMatch 404 ^/.*_vti_bot/(.*)$
>> RedirectMatch 404 ^/.*_vti_log/(.*)$
>> RedirectMatch 404 ^/.*_vti_pvt/(.*)$
>> RedirectMatch 404 ^/.*_vti_shm/(.*)$
>> RedirectMatch 404 ^/.*_vti_txt/(.*)$
>> RedirectMatch 404 ^/.*webmaster_logs/(.*)$
>> RedirectMatch 404 ^/.*wwwlog/(.*)$
>> RedirectMatch 404 ^/.*~
>> RedirectMatch 404 ^/.*Administration/(.*)$
>> RedirectMatch 404 ^/.*AdvWebAdmin/(.*)$
>> RedirectMatch 404 ^/.*asp/(.*)$
>> RedirectMatch 404 ^/.*aspx/(.*)$
>> RedirectMatch 404 ^/.*authadmin/(.*)$
>> RedirectMatch 404 ^/.*BizTalkServerRepository/(.*)$
>> RedirectMatch 404 ^/.*blindblog/(.*)$
>> RedirectMatch 404 ^/.*cbblog/(.*)$
>> RedirectMatch 404 ^/.*ccards/(.*)$
>> RedirectMatch 404 ^/.*centreon/(.*)$
>> RedirectMatch 404 ^/.*certificate/(.*)$
>> RedirectMatch 404 ^/.*cgi-auth/(.*)$
>> RedirectMatch 404 ^/.*cgi-bin2/(.*)$
>> RedirectMatch 404 ^/.*cgi-bin/(.*)$
>> RedirectMatch 404 ^/.*cgi-csc/(.*)$
>> RedirectMatch 404 ^/.*cgi-isapi/(.*)$
>> RedirectMatch 404 ^/.*cgi-lib/(.*)$
>> RedirectMatch 404 ^/.*cgi-local/(.*)$
>> RedirectMatch 404 ^/.*cgi-public/(.*)$
>> RedirectMatch 404 ^/.*cgi-shl/(.*)$
>> RedirectMatch 404 ^/.*cgi-shl/(.*)$
>> RedirectMatch 404 ^/.*cgi-shop/(.*)$
>> RedirectMatch 404 ^/.*cgi-sys/(.*)$
>> RedirectMatch 404 ^/.*cgi-weddico/(.*)$
>> RedirectMatch 404 ^/.*cgi-win/(.*)$
>> RedirectMatch 404 ^/.*cgiwin/(.*)$
>> RedirectMatch 404 ^/.*commoncgi/(.*)$
>> RedirectMatch 404 ^/.*console/(.*)$
>> RedirectMatch 404 ^/.*ControlManager/(.*)$
>> RedirectMatch 404 ^/.*cs-dns/(.*)$
>> RedirectMatch 404 ^/.*cs-whois/(

Last call... STATUS needing one sec fix vote [was Re: Roll 2.2.30]

[William A Rowe Jr]

On Jun 18, 2015 1:45 PM, "William A Rowe Jr"  wrote:
>
> On Jun 11, 2015 8:22 AM, "Eric Covener"  wrote:
> >
> > On Thu, Jun 11, 2015 at 9:08 AM William A Rowe Jr 
wrote:
> >>
> >> But withholding a security fix for legacy server users?  Sounds like a
way to earn distrust of the user community, not reassure them that 2.4.14
is the best version available.
> >
> > +1
>
> The 2.2 patches are in alignment with the resolved 2.4 security patches
plus relaxed trailing spaces rule. Yann and I have reviewed, still weeks
later 2.2.30 needs one more pair of eyeballs and a third +1 of the 2
patches.
>
> I can T&R in the morning Friday if it has been reviewed, else it will be
a while before I can RM.

If there is a vote in the next 90 minutes, I'll proceed, otherwise I can
proceed sometime next week after missing +1 is cast.

Re: Roll 2.2.30 in conjunction with 2.4.14

[William A Rowe Jr]

On Jun 11, 2015 8:22 AM, "Eric Covener"  wrote:
>
> On Thu, Jun 11, 2015 at 9:08 AM William A Rowe Jr 
wrote:
>>
>> But withholding a security fix for legacy server users?  Sounds like a
way to earn distrust of the user community, not reassure them that 2.4.14
is the best version available.
>
> +1

The 2.2 patches are in alignment with the resolved 2.4 security patches
plus relaxed trailing spaces rule. Yann and I have reviewed, still weeks
later 2.2.30 needs one more pair of eyeballs and a third +1 of the 2
patches.

I can T&R in the morning Friday if it has been reviewed, else it will be a
while before I can RM.

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

[William A Rowe Jr]

In some cases, perhaps, but this was objection asked-and-answered so my -1
was void.

On Thu, Jun 18, 2015 at 12:07 PM, Yann Ylavic  wrote:

> On Thu, Jun 18, 2015 at 5:39 PM,   wrote:
> > Author: wrowe
> > Date: Thu Jun 18 15:39:53 2015
> > New Revision: 1686248
> >
> > URL: http://svn.apache.org/r1686248
> > Log:
> > After addressing a defect, don't discuss, this isn't a forum :)
> >
> > Note the patch is updated, and delete now-irrelevant comments/votes.
>
> It seems to me that since a -1 needs to be argued, it can't be deleted
> without..
>

Re: TWS ";" LWS permitted by RFC 7230 4.1.1? Apparently, no.

[William A Rowe Jr]

Note in STATUS I've requested that you split the approved patch from
security@ that seemed to be lost in long and winding patch versioning from
the spaces accepted.  A patch should correct one thing, not several, it
makes these too difficult to review when folks have a small window of free
time.  Your proposed rolled-up patch didn't correspond to trunk, and the
'parsing' flag seems unnecessary.  Two error messages would have been
easier on reviewers anyways.

Hopefully all constructive criticism easily agreed to?



On Tue, Jun 16, 2015 at 12:31 PM, Yann Ylavic  wrote:

> On Tue, Jun 16, 2015 at 7:22 PM, Jim Jagielski  wrote:
> > Sooo in order to get 2.4.15 out, it would be nice to have
> > a patch :)
>
> Isn't the one proposed in STATUS suitable (section SHOWSTOPPERS)?
> It has been positively tested by Steffen in [1] and also passes the
> new framework tests from [2].
>
> [1]
> http://mail-archives.apache.org/mod_mbox/httpd-dev/201506.mbox/%3CFB1A6FB8F6F046AAA243E9583A4CA9BD%40father%3E
> [2] http://svn.apache.org/r1685463
>

Re: TWS ";" LWS permitted by RFC 7230 4.1.1? Apparently, no.

[William A Rowe Jr]

On Jun 15, 2015 6:11 PM, "Roy T. Fielding"  wrote:
>
> > On Jun 15, 2015, at 9:33 AM, William A Rowe Jr 
wrote:
> >
> > Reviewing the spec, I cannot find where Sambar server is permitted to
insert whitespace. I further reviewed the ABNF appendix, and it does not
appear there, either.
>
> Right, this was a deliberate decision to reduce the number of infinite
stream possibilities.
> We can still read a few SP and discard for robustness, but it should be
limited to the same
> few characters as leading zeros.

So as things stand, this is BWS (or just drop the W :)  As such we don't
pass it through verbatim, so we are honoring the BWS contract of not
repeating the mistake.  With HttpStrict on head, we can return to Yann's
original proposal of treating such headers as errors.

> Sambar Server has been EOL for 7 years with no available source code for
review, so it's
> behavior is no longer relevant to the standard.

+1

Re: TWS ";" LWS permitted by RFC 7230 4.1.1? Apparently, no.

[William A Rowe Jr]

On Jun 15, 2015 1:26 PM, "Graham Leggett"  wrote:
>
> On 15 Jun 2015, at 7:00 PM, Jeff Trawick  wrote:
>
> > 1.3 (or 1.3-based servers) put whitespace there.
> > 1.3.x, 2.0.x, 2.2.x, and 2.4.x (for all released x so far) accepts
whitespace there.
> > We can't change that by default in a stable branch.
>
> +1.
>
> We need to be liberal in what we accept. I don’t even think a “strict”
mode serves much purpose.

That 'thinking' by many server authors created the stack of CVE-2005 issues
identified by Watchfire as low, medium and worse severities.

This is not metadata.  It is transport-layer data.  And we have precedent
for closing vulnerabilities in 2005, and the several SSL vendors have done
similar.

That said, httpd 2 has always done the right thing with respect to not
passing hop-by-hop data verbatim.  So we are in a bit better position than
some, and this mitigates the surface area of the attack.

The recent enhancements to further protect from split requests is also
reassuring.

TWS ";" LWS permitted by RFC 7230 4.1.1? Apparently, no.

[William A Rowe Jr]

Reviewing the spec, I cannot find where Sambar server is permitted to
insert whitespace. I further reviewed the ABNF appendix, and it does not
appear there, either.

The spec seems unambiguous;

chunk  = chunk-size [ chunk-ext ] CRLF
 chunk-data CRLF
chunk-size = 1*HEXDIG
last-chunk = 1*("0") [ chunk-ext ] CRLF


There is no opportunity to use whitespace outside of chunk-ext.


chunk-ext  = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val  = token / quoted-string


The rules in section 3.2.3 have become extremely strict;


3.2.3 .  Whitespace

   This specification uses three rules to denote the use of linear
   whitespace: OWS (optional whitespace), RWS (required whitespace), and
   BWS ("bad" whitespace).

   The OWS rule is used where zero or more linear whitespace octets
   might appear.  For protocol elements where optional whitespace is
   preferred to improve readability, a sender SHOULD generate the
   optional whitespace as a single SP; otherwise, a sender SHOULD NOT
   generate optional whitespace except as needed to white out invalid or
   unwanted protocol elements during in-place message filtering.

   The RWS rule is used when at least one linear whitespace octet is
   required to separate field tokens.  A sender SHOULD generate RWS as a
   single SP.

   The BWS rule is used where the grammar allows optional whitespace
   only for historical reasons.  A sender MUST NOT generate BWS in
   messages.  A recipient MUST parse for such bad whitespace and remove
   it before interpreting the protocol element.


And section 3.6.1 of RFC2616 made no accommodation for whitespace, in
the first place.


I think Sambar is wrong and we should not be supporting this.


If we make provision to support this, we should be disallowing

by default and add a directive to change the behavior.


Thoughts?

Re: SSLCertificateChainFile deprecation, still

[William A Rowe Jr]

On Mon, Jun 15, 2015 at 8:12 AM, Eric Covener  wrote:

> Anyone else inclined to just remove the message? It's a deprecation that
> didn't happen on a release boundary. AFAICT there's no reason to change how
> you run your server unless you use two different cert chains and then you'd
> find the info in the manual.
>

+1, this is highly irregular.  Our general statement is that config changes
are not strictly necessary on subversion updates of httpd.  (Securing your
SSLCipherList notwithstanding.)

Bill

Re: [VOTE] Release Apache httpd 2.4.14 as GA

[William A Rowe Jr]

On Jun 14, 2015 12:45 PM, "Jim Jagielski"  wrote:
>
> I am canceling this vote... The breakage due to the chunked
> stuff is the reason.
>
> THIS is the reason I don't like "last-minute" changes that
> (1) touch a LOT of code or a major code path and (2) has an
> extremely limited QA history. We should also patch the test
> framework to test for this.

This is the reason I dont like security patches, but they are a fact of
life.  Sadly this one would not have been discovered without the breadth of
interop testing that a release vote entails.

Mad props to Steffan for identifying this bug, outstanding!  Thank you.

> Let's patch this and I will T&R 2.4.15 this week.

+1.  More interop testing in the meantime is most welcomed.

Re: [VOTE] Release Apache httpd 2.4.14 as GA

[William A Rowe Jr]

Revision 1678233 - (view) (download) (annotate) - [select for diffs]
Modified Thu May 7 16:26:43 2015 UTC (5 weeks, 1 day ago) by jim
File length: 57106 byte(s)
Diff to previous 1674655 (colored)
Merge r1676085 from trunk:

consistently output SSLCertificateChainFile deprecation warnings
Submitted by: kbrand
Reviewed/backported by: jim

sent the warnings to the console/main server error log, rather than a
specific server error log file.  Because this is during config parsing, it
that may have previously been a bit bucket.  So this could be perceived as
a regression although the logic and log file activity was there for some
time.



On Fri, Jun 12, 2015 at 11:58 AM, Eric Covener  wrote:

> It doesn't make sense for us to hold up a release when that change has
>>> been in the last several releases however.  (That's a high barrier for
>>> making progress.)
>>>
>>>
> There seems to be a 2.4.8 component and an actual 2.4.13 component. Did
> the 2.4.13 fix make it more frequent.
>
> (fixing my top-post)
>

Re: svn commit: r1685052 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_config.c

[William A Rowe Jr]

On Fri, Jun 12, 2015 at 8:36 AM, Rainer Jung 
wrote:

> Am 12.06.2015 um 13:49 schrieb Yann Ylavic:
>
>> Hi Christophe,
>>
>> On Fri, Jun 12, 2015 at 1:26 PM, Christophe JAILLET
>>  wrote:
>>
>>>
>>> should this warning at startup be an issue, why not just remove it in
>>> 2.4.x
>>> and keep it in trunk?
>>> Having the depreciation written in doc (and in migration note for 2.4 ->
>>> 2.6/3.0 one day) could be enough, no?
>>>
>>
>> Probably, but the (only one) warning per startup can possibly
>> encourage users to look at the doc :)
>> Let's see what others say.
>>
>
> I don't have a strong opinion, but if we want to remove the directive in
> the next version, then it would help to keep the deprecation logging to
> make people aware and reduce the migration complains a bit.
>
> Logging only once instead of for each certificate is IMHO enough and much
> better.
>

Agreed, although this is never a [warn], it's [info] at strongest.


> As to if the current situation in 2.4.14 is a problem or should be
> tolerated (lots of log output for people with huge numbers of certificates)
> I'm quite undecided.
>

Trivial patch, easily applied by the tiny few who would be affected, so I
don't think it has any impact on the 2.4.14 readiness for GA.

Bill

Patch: message received and acknowledged;

--- modules/ssl/ssl_engine_config.c (revision 8078)
+++ modules/ssl/ssl_engine_config.c (working copy)
@@ -862,7 +862,7 @@
 SSLSrvConfigRec *sc = mySrvConfig(cmd->server);
 const char *err;

-ap_log_error(APLOG_MARK, APLOG_WARNING|APLOG_STARTUP, 0, NULL,
+ap_log_error(APLOG_MARK, APLOG_DEBUG|APLOG_STARTUP, 0, NULL,
  APLOGNO(02559)
  "The SSLCertificateChainFile directive (%s:%d) is
deprecated, "
  "SSLCertificateFile should be used instead",

Re: [VOTE] Release Apache httpd 2.4.14 as GA

[William A Rowe Jr]

This is corrected in SVN, see

http://svn.apache.org/viewvc/httpd/httpd/trunk/server/request.c?view=log

Unsure why this edit didn't carry on to the github mirror.

On Thu, Jun 11, 2015 at 11:50 AM, Rainer Canavan <
rainer.cana...@sevenval.com> wrote:

> Hi,
>
> is the commit message incorrect or the CHANGES file concerning
> CVE-2015-3183?
>
> The commit message at
>
> https://github.com/apache/httpd/commit/cd2b7a26c776b0754fb98426a67804fd48118708
> uses CVE-2015-3183 for the "Replacement of ap_some_auth_required",
> while the CHANGES uses it for "Remove apr_brigade_flatten()"
>
> I'm have no idea if that would qualify the CVE to get REJECTED.
>
> regards,
>
>
> rainer
>

Re: httpd 2.4 and windows "hangs" and AcceptFilter solution

[William A Rowe Jr]

On Thu, Jun 11, 2015 at 11:09 AM, Andy Wang  wrote:

>
> On 06/11/2015 09:02 AM, William A Rowe Jr wrote:
>
>>
>> Sounds telling.  Can you get your installer to stall without invoking
>> httpd.exe - and then attempt to start httpd outside of the installer on
>> the same machine?  Something going on within the installer may be
>> interacting with the winsock stack.  If so, with the installer frozen
>> the problem should occur outside of the installer process, I'd expect.
>>
>>
> The installer never actually stalls either. it continues to process a few
> things and then eventually it needs to make a request to httpd to make sure
> it's up.  At that point, the installer hangs waiting for response.  the
> interesting thing is the TCP handshake and GET request are both actually
> completed, so there's no other timeout.  So the process primary thread is
> "hung" because of that.  However all other threads are perfectly fine (JMX
> monitoring can connect to it, i can get jstack thread dumps, etc etc)
>
> The only thing that appers to be hanging is httpd.exe but even then it's
> not hung in the sense that anything is blocked.. processexplorer/monitor
> show everything to be simply waiting for requests that the windows tcp
> stack simply isn't passing to it.


Got all that, I suggested you stall it deliberately.  Comment out
invocation of httpd.exe; then put a 20 minute 'sleep' in the installer
logic when it would typically query the browser.

While running the installer package, now try using httpd.exe with the same
config, etc outside of the installer entirely, and see if it responds.
This will indicate if there is something in the installer that has messed
up the network stack.


>  One of the other windows guys here, theorized that it has to do with
>> inherited handles but he couldn't really work out why.  He's not a
>> winsock expert though.
>>
>>
>> A possibility.  There is the -X (-DONE_PROCESS) startup flag to rule
>> that out.
>>
>>
> If I get some free time, I nmight try to reproduce this and document some
> of the above thread analysis. It's not  ahuge problem for me. We've been
> deploying httpd 2.2.x with Win32DisableAcceptEx configured the whole time.
> When I migrated to 2.4.x I didn't move tha tforward to the Acceptfilter
> configuration because i didn't know for sure why we needed it and i
> thought, hey new httpd.exe version, why not try and see what happens.
>

Yes, AcceptFilter none is semantically identical to Win32DisableAcceptEx.
Otherwise, AcceptEx() is used in one of two different modes to ensure that
a packet of data was received before signalling httpd that a connection is
established.

Re: httpd 2.4 and windows "hangs" and AcceptFilter solution

[William A Rowe Jr]

On Thu, Jun 11, 2015 at 8:48 AM, Andy Wang  wrote:

>
> Pleading windows ignorance here, but what kind of permissions problem?
> Both processes are elevated to administrator via UAC (or with UAC disabled)
> and literally as soon as you kill the parent java.exe process, it starts to
> work.
>

Sounds telling.  Can you get your installer to stall without invoking
httpd.exe - and then attempt to start httpd outside of the installer on the
same machine?  Something going on within the installer may be interacting
with the winsock stack.  If so, with the installer frozen the problem
should occur outside of the installer process, I'd expect.


> One of the other windows guys here, theorized that it has to do with
> inherited handles but he couldn't really work out why.  He's not a winsock
> expert though.


A possibility.  There is the -X (-DONE_PROCESS) startup flag to rule that
out.

Re: Roll 2.2.30 in conjunction with 2.4.14

[William A Rowe Jr]

I believe the opposite, that the announcement 2.4 contains enhancements,
bug fixes, and security fixes, and 2.2 legacy containing security fixes
will set user expectations.  A later 2.2 announce muddies the waters when
users ponder if it is 'current' and sufficient.  We have language in both
files to clarify this, but still...

Another way to put it is that 2.2.30 shouldn't be a headline and receive
its own announcement, but sit as a sidebar of our significant public
message that 2.4 release is out.

But withholding a security fix for legacy server users?  Sounds like a way
to earn distrust of the user community, not reassure them that 2.4.14 is
the best version available.  Whose interest does that serve?

Not ours, it leaves the risk in place between 2.2 and 2.4 instances because
request splitting attacks require agents to interpret request length
indications differently.  Updating every affected server is the responsible
action by the user, and a security release is rarely a smart moment in time
to perform a major upgrade (config changes etc) without proper testing of
those configs and services.
 On Jun 11, 2015 4:27 AM, "Steffen"  wrote:

>   Not so happy to roll 2.2.30 in conjunction with 2.4.14.
>
> It does not stimulate pp to upgrade to 2.4., it suggest that the
> httpd-project gives 2.2 (legacy) the same priority as 2.4.
>
> Better first 2.4 and after some time 2.2. I do not agree with the argument
> to simplify the announcement.
>
>
>
>  *From:* William A Rowe Jr 
> *Sent:* Thursday, June 11, 2015 4:54 AM
> *Newsgroups:* gmane.comp.apache.devel
> *To:* httpd 
> *Subject:* Re: Review of 2.2.x security patch sought.
>
>  Just a quick /nag that I'm happy to roll 2.2.30 in conjunction with
> 2.4.14,
> so that we present both to the community at the same time, and simplify
> the announcement.  This patch still needs a third +1 to be adopted (it is
> already in trunk, and in the 2.4.14 Jim will be tagging & rolling shortly).
>
> ...
> ...
> ...
>

Re: Review of 2.2.x security patch sought.

[William A Rowe Jr]

Just a quick /nag that I'm happy to roll 2.2.30 in conjunction with 2.4.14,
so that we present both to the community at the same time, and simplify
the announcement.  This patch still needs a third +1 to be adopted (it is
already in trunk, and in the 2.4.14 Jim will be tagging & rolling shortly).

Apologies for being short on details until the announcement, but in short,
the way httpd interpreted chunk headers didn't follow the RFC.  This may
lead to similar circumstances as were exploited with CVE-2005-2088.
The project currently rates this risk as low, but as security vendors, such
as Watchfire, mapped how other backend and proxy implementations
interacted with httpd itself, CVE-2005-2088 was upgraded to medium
severity.  That is a possibility and the reason for requesting review of the
2.2 backport, on an expedited basis.







On Tue, Jun 9, 2015 at 3:32 PM, William A Rowe Jr 
wrote:

> Committers,
>
> we ended up short on reviewers in the security list, and are proceeding
> shortly with 2.4.14.
>
> I can't proceed with 2.2.30 until I get a third set of eyeballs on the
> 2.2.30-dev backport,
> could someone offer to review ASAP?  I will be tagging once the backport
> is approved,
> no other changes to 2.2.x. branch until 2.2.31-dev.
>
> The defect is considered Low severity based on httpd team's initial
> assessment.
> The other patch coming in a moment doesn't apply to 2.2.x at all.
>
> On Tue, Jun 9, 2015 at 3:26 PM,  wrote:
>
>> Adjust URL for public consumption
>>
>> Modified:
>> httpd/httpd/branches/2.2.x/STATUS
>>
>> Modified: httpd/httpd/branches/2.2.x/STATUS
>> URL:
>> http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?rev=1684520&r1=1684519&r2=1684520&view=diff
>>
>> ==
>> --- httpd/httpd/branches/2.2.x/STATUS (original)
>> +++ httpd/httpd/branches/2.2.x/STATUS Tue Jun  9 20:26:47 2015
>> @@ -109,12 +109,12 @@ RELEASE SHOWSTOPPERS:
>>Reported by: Régis Leroy
>>
>>trunk
>> +http://svn.apache.org/r1484852
>> +http://svn.apache.org/r1684513
>>2.4.x branch
>> +http://svn.apache.org/r1684515
>>2.2.x branch
>> +
>> http://people.apache.org/~wrowe/httpd-2.2.x-ap_http_filter-chunked-v6.patch
>>+1: ylavic, wrowe
>>jim notes: test framework errors due to 413->400 error change [test
>> adjusted]
>>
>>
>>
>>
>

Re: httpd 2.4 and windows "hangs" and AcceptFilter solution

[William A Rowe Jr]

On Wed, Jun 10, 2015 at 4:12 PM, Andy Wang  wrote:

> I can reproduce the first case with the installer, pretty much ondemand
> using our installer stuff.  I've tried reproducing it by ripping out the
> actions that do the Runtime.exec() to call httpd.exe into a separate
> standalone program, and the problem doesn't occur there.  Go figure. But
> when this occurs httpd.exe is unresponsive to localhost AND remote traffic
> immediately.  I think I can get one or maybe 2 requests in and out before
> it additional connections simply hang until a network timeout.  Wireshark
> shows the request is ACKed but that's it.
>
> My initial thought was that something cause the process to be blocked, but
> from what I can tell from Process Explorer/Process Monitor the threads look
> correct and are simply waiting for a request.
>

This sounds like a permissions problem.


> The internet explorer 11 case, I've not seen myself, just from reports of
> other developers I've worked with. It occurs from automated tests, and
> these are mostly remote clients running IE11.


It is possible that the 'data' mode (that ships the first packet(s) into
buffers upon receiving data) is somehow incompatible with a broken IE11
handshake.

Re: httpd 2.4 and windows "hangs" and AcceptFilter solution

[William A Rowe Jr]

Can you reproduce using the real network driver?  The loopback/localhost
interface is famously junk.
 On Jun 10, 2015 11:22 AM, "Andy Wang"  wrote:

> Yeah, that much I more or less get.
>
> What I really don't understand is what can a client do (IE11) that would
> regularly cause httpd.exe to hang with AcceptEx.  This is reproducible on
> every single machine I've ever tried, including completely vanilla virtual
> machines, or pretty straightforward physical machines with intel NICs and
> no additional stack drivers.  That seems like a pretty hideous architecture
> if a regular non-malicious client requests could end up causing the web
> server to simply stop responding.
>
> The InstallAnywhere problem I mentioned is also reliably reproduced on
> every single Windows system I've tried this on (about a dozen different
> systems with different configurations - virtual and physical).  This is the
> one I especially can't understand.  How would launching httpd.exe from a
> installer process (java.exe specifically) prevent it from responding to
> requests.
>
> Andy
>
> On 06/10/2015 10:48 AM, William A Rowe Jr wrote:
>
>> It turns off all advanced socket mechanics for accepting connections.
>> That means
>> it won't pre-fetch data.  Because of how cobbled-together the WinSock
>> network
>> stack drivers (third parties, included) were, there are many things that
>> break
>> sendfile (disable sendfile) or socket reuse (disable advanced accept
>> logic).
>>
>> In other words, if you need reliability on some pretty crazy
>> installations of
>> Windows with lots of out-of-date drivers, your solution is the way to
>> go.  They
>> are for performance, there is no reason to turn these on in low-traffic
>> cases.
>>
>>
>> On Wed, Jun 10, 2015 at 10:31 AM, Andy Wang > <mailto:aw...@ptc.com>> wrote:
>>
>> I originally asked this on user@httpd and didn't get a response, so
>> thought I'd redirect to dev and see if anyone can explain why this
>> would occur if you have time.  I have to admit, it's a curiosity to
>> me, that I just don't want to let go until I understand it and what
>> research I've done into AcceptEx doesn't seem to be giving me any
>> more insight.
>>
>> --- original message ---
>>
>> We've come across numerous cases where apache httpd 2.4 (I'm using
>> 2.4.12 but I don't believe this is version specific) hang using the
>> default configuration options.
>>
>> There are two cases
>> 1) we have an InstallAnywhere installer that launches httpd during
>> install time to do some initial work.  When the installanywhere
>> installer starts httpd.exe (it does it via cmd.exe) httpd does not
>> respond to requests.  If you kill the installanywhere installer, then
>> all of the sudden httpd starts responding
>> 2) certain IE 11 client requests hang httpd 2.4.
>>
>> I've wireshark'ed #2 and at some point, an http GET gets an ACK and
>> nothing more.  I've peeked a little bit at the process threads with
>> processexplorer (unfortunately i'm not a windows developer, so I'm not
>> entirely familiar with the low level windows stuff) and everyhting
>> looks
>> like it's okay and simply waiting for requests.
>>
>> What I found after googling and testing is AcceptFilter http|https
>> none
>> prevents both of those problems.  I've not yet tried connect to see if
>> that works either.
>>
>> But what I'm really wondering about is, can anyone explain, especially
>> in #2, what it is about AcceptFilter http none that actually resolves
>> these types of issues?
>>
>> Thanks,
>> Andy
>>
>>
>>
>>
>>
>>

Re: httpd 2.4 and windows "hangs" and AcceptFilter solution

[William A Rowe Jr]

It turns off all advanced socket mechanics for accepting connections.  That
means
it won't pre-fetch data.  Because of how cobbled-together the WinSock
network
stack drivers (third parties, included) were, there are many things that
break
sendfile (disable sendfile) or socket reuse (disable advanced accept logic).

In other words, if you need reliability on some pretty crazy installations
of
Windows with lots of out-of-date drivers, your solution is the way to go.
They
are for performance, there is no reason to turn these on in low-traffic
cases.


On Wed, Jun 10, 2015 at 10:31 AM, Andy Wang  wrote:

> I originally asked this on user@httpd and didn't get a response, so
> thought I'd redirect to dev and see if anyone can explain why this would
> occur if you have time.  I have to admit, it's a curiosity to me, that I
> just don't want to let go until I understand it and what research I've done
> into AcceptEx doesn't seem to be giving me any more insight.
>
> --- original message ---
>
> We've come across numerous cases where apache httpd 2.4 (I'm using
> 2.4.12 but I don't believe this is version specific) hang using the
> default configuration options.
>
> There are two cases
> 1) we have an InstallAnywhere installer that launches httpd during
> install time to do some initial work.  When the installanywhere
> installer starts httpd.exe (it does it via cmd.exe) httpd does not
> respond to requests.  If you kill the installanywhere installer, then
> all of the sudden httpd starts responding
> 2) certain IE 11 client requests hang httpd 2.4.
>
> I've wireshark'ed #2 and at some point, an http GET gets an ACK and
> nothing more.  I've peeked a little bit at the process threads with
> processexplorer (unfortunately i'm not a windows developer, so I'm not
> entirely familiar with the low level windows stuff) and everyhting looks
> like it's okay and simply waiting for requests.
>
> What I found after googling and testing is AcceptFilter http|https none
> prevents both of those problems.  I've not yet tried connect to see if
> that works either.
>
> But what I'm really wondering about is, can anyone explain, especially
> in #2, what it is about AcceptFilter http none that actually resolves
> these types of issues?
>
> Thanks,
> Andy
>
>
>
>
>

Review of 2.2.x security patch sought.

[William A Rowe Jr]

Committers,

we ended up short on reviewers in the security list, and are proceeding
shortly with 2.4.14.

I can't proceed with 2.2.30 until I get a third set of eyeballs on the
2.2.30-dev backport,
could someone offer to review ASAP?  I will be tagging once the backport is
approved,
no other changes to 2.2.x. branch until 2.2.31-dev.

The defect is considered Low severity based on httpd team's initial
assessment.
The other patch coming in a moment doesn't apply to 2.2.x at all.

On Tue, Jun 9, 2015 at 3:26 PM,  wrote:

> Adjust URL for public consumption
>
> Modified:
> httpd/httpd/branches/2.2.x/STATUS
>
> Modified: httpd/httpd/branches/2.2.x/STATUS
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?rev=1684520&r1=1684519&r2=1684520&view=diff
>
> ==
> --- httpd/httpd/branches/2.2.x/STATUS (original)
> +++ httpd/httpd/branches/2.2.x/STATUS Tue Jun  9 20:26:47 2015
> @@ -109,12 +109,12 @@ RELEASE SHOWSTOPPERS:
>Reported by: Régis Leroy
>
>trunk
> +http://svn.apache.org/r1484852
> +http://svn.apache.org/r1684513
>2.4.x branch
> +http://svn.apache.org/r1684515
>2.2.x branch
> +
> http://people.apache.org/~wrowe/httpd-2.2.x-ap_http_filter-chunked-v6.patch
>+1: ylavic, wrowe
>jim notes: test framework errors due to 413->400 error change [test
> adjusted]
>
>
>
>

Re: svn commit: r1684457 - /httpd/httpd/branches/2.2.x/STATUS

[William A Rowe Jr]

I don't entirely understand the patch CHANGES, however...

On Tue, Jun 9, 2015 at 10:41 AM,  wrote:

>  PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
>[ start all new proposals below, under PATCHES PROPOSED. ]
>
> * mod_ssl: bring SNI behavior into better conformance with RFC 6066
>   (also addresses PR 56241)
>   trunk patch: https://svn.apache.org/r1585090
>(partial, w/o startup warnings changes)
>   2.4.x patch: https://svn.apache.org/r1588424
>(backported to 2.4.10)
>   2.2.x patch:
> http://people.apache.org/~ylavic/httpd-2.2.x-no_sni_warning.patch
> + +1: ylavic, jorton, wrowe
>

The patch claims both adjusting alerts and changing startup behavior...

--- CHANGES (revision 1684331)
+++ CHANGES (working copy)
@@ -1,6 +1,11 @@
  -*- coding: utf-8 -*-
 Changes with Apache 2.2.30

+  *) mod_ssl: bring SNI behavior into better conformance with RFC 6066:
+ no longer send warning-level unrecognized_name(112) alerts,
+ and limit startup warnings to cases where an OpenSSL version
+ without TLS extension support is used. PR 56241. [Kaspar Brand]
+
   *) http: Make ap_die() robust against any HTTP error code and not modify
  response status (finally logged) when nothing is to be done.
[Yann Ylavic]


But the patch contains only the first change to code.

@@ -1962,7 +1962,21 @@ int ssl_callback_ServerNameIndication(SSL *ssl, in
   "No matching SSL virtual host for servername "
   "%s found (using default/first virtual host)",
   servername);
-return SSL_TLSEXT_ERR_ALERT_WARNING;



Everything else is commentary.  When you backport, Yann, would you correct
the message?

STATUS and Backport Review efficiency

[William A Rowe Jr]

I've noticed this happening more and more often...

http://httpd.markmail.org/search/?q=+list%3Aorg.apache.httpd.cvs+%22vote+discarded%22

Here's one arbitrary example - there are many committers implicated here...


--- httpd/httpd/branches/2.4.x/STATUS (original) +++
httpd/httpd/branches/2.4.x/STATUS Sat May 16 10:17:05 2015 @@ -205,10
+205,17 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
http://svn.apache.org/r1640763 http://svn.apache.org/r1643179
http://svn.apache.org/r1656368 - 2.4.x patch:
http://people.apache.org/~jim/patches/httpd-2.4.x-ap_listeners_buckets-v2.patch
- +1: ylavic, jim + http://svn.apache.org/r1679714 + 2.4.x patch:
http://people.apache.org/~ylavic/httpd-2.4.x-ap_listeners_buckets-v3.patch
+ +1: ylavic wrowe: the statics are not explicitly initialized for clarity
ap_log_common is horribly named, perhaps ap_log_mpm_common()? + ylavic: v3
with s/ap_log_common/ap_log_mpm_common/ (jim's *vote discarded*). + globals
(including statics) not initialized are implicitely
initialized to zero + per C standard, and go to .bss (zeroed as a whole at
load time),
whereas the ones + explicitly initialized (even to 0 depending on the
compiler/flags)
go to .data and + have each to be set to their init value (which may take
some
cycles at load time). + I personaly don't see explicit initializations to
{0} as a win
(even for clarity...).

*) http: Make ap_die() robust against any HTTP error code and not modify
response status (finally logged) when nothing is to be done. PR 56035.


In this example, the patch was enhanced and the original reviewers' efforts
were thrown away. It's a shame to waste the limited review cycles.

Moving forwards, can we please do two things.  1) retain the original patch
and vote in the STATUS, adding a revised patch below the vote that can be
reviewed, and 2) show the changelog of patch 1 vs. patch 2 so that the
original reviewer doesn't have to bisect two patches to determine whether
the change had any measurable effect on the original patch review?

We might start an
http://svn.apache.org/repos/asf/httpd/httpd/patches/backports/2.[24].x/
tree, so that viewvc can be helpful in this respect, instead of multiple
patches residing in our individual public_html/ trees. WDYAT?

All of this is to say that we should pay extra close attention to
correctness when we first submit a backport patch proposal, and request 3)
is to please not use STATUS as a discussion tool.  If the
comment/observation doesn't fit in 240 characters (3 lines), it probably
belongs on the list instead, or can be a short note in STATUS with a long
explanation on dev.

Re: [VOTE] Release Apache httpd 2.4.13 as GA

[William A Rowe Jr]

On Thu, Jun 4, 2015 at 11:33 AM, Jim Jagielski  wrote:

> The pre-release test tarballs for Apache httpd 2.4.13 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'm calling a VOTE on releasing these as Apache httpd 2.4.13 GA.
>
> [X] -1: Danger Will Robinson. And why.
>

httpd project policies prevent me from explaining "why", which has been
explained in confidence.  This is simply a vote, releases don't get 'vetos'.

Re: mod_deflate was Re: [VOTE] Release Apache httpd 2.4.13 as GA

[William A Rowe Jr]

On Fri, Jun 5, 2015 at 1:05 AM, William A Rowe Jr 
wrote:

> On Fri, Jun 5, 2015 at 12:42 AM, Christophe JAILLET <
> christophe.jail...@wanadoo.fr> wrote:
>>
>> This has been fixed in trunk in r1619453. ( APLOGNO(02805) )
>
>
> Would you propose the backport?  TIA!
>

And... I see you did :)  Thanks again.

Re: mod_deflate was Re: [VOTE] Release Apache httpd 2.4.13 as GA

[William A Rowe Jr]

On Fri, Jun 5, 2015 at 12:42 AM, Christophe JAILLET <
christophe.jail...@wanadoo.fr> wrote:
>
> This has been fixed in trunk in r1619453. ( APLOGNO(02805) )


Would you propose the backport?  TIA!

Re: mod_deflate was Re: [VOTE] Release Apache httpd 2.4.13 as GA

[William A Rowe Jr]

I'm not compiling -Wall... so

/opt/apr15/build-1/libtool --silent --mode=compile gcc -std=gnu99
-I/usr/include/libxml2 -g -O2 -pthread  -DLINUX -D_REENTRANT
-D_GNU_SOURCE -I. -I/home/wrowe/dev/httpd-2.4/os/unix
-I/home/wrowe/dev/httpd-2.4/include -I/opt/apr15/include/apr-1
-I/usr/local/ssl/include -I/usr/local/include
-I/home/wrowe/dev/httpd-2.4/modules/aaa
-I/home/wrowe/dev/httpd-2.4/modules/cache
-I/home/wrowe/dev/httpd-2.4/modules/core
-I/home/wrowe/dev/httpd-2.4/modules/database
-I/home/wrowe/dev/httpd-2.4/modules/filters
-I/home/wrowe/dev/httpd-2.4/modules/ldap -I/home/wrowe/dev/httpd-2.4/server
-I/home/wrowe/dev/httpd-2.4/modules/loggers
-I/home/wrowe/dev/httpd-2.4/modules/lua
-I/home/wrowe/dev/httpd-2.4/modules/proxy
-I/home/wrowe/dev/httpd-2.4/modules/session
-I/home/wrowe/dev/httpd-2.4/modules/ssl
-I/home/wrowe/dev/httpd-2.4/modules/test -I/home/wrowe/dev/httpd-2.4/server
-I/home/wrowe/dev/httpd-2.4/modules/arch/unix
-I/home/wrowe/dev/httpd-2.4/modules/dav/main
-I/home/wrowe/dev/httpd-2.4/modules/generators
-I/home/wrowe/dev/httpd-2.4/modules/mappers -prefer-pic -c mod_deflate.c &&
touch mod_deflate.slo
/opt/apr15/build-1/libtool --silent --mode=link gcc -std=gnu99
-I/usr/include/libxml2 -g -O2 -pthread -L/usr/local/ssl/lib  -o
mod_deflate.la -rpath /opt/apache24/modules -module -avoid-version
 mod_deflate.lo -lz

no noise on compilation.  I'm not debating it isn't there, just that my
compiler settings did not throw it at me.

On Fri, Jun 5, 2015 at 12:11 AM, Gregg Smith  wrote:

> On 6/4/2015 10:01 PM, William A Rowe Jr wrote:
>
>> On Thu, Jun 4, 2015 at 10:47 PM, Gregg Smith  wrote:
>>
>>  This is new, not quite sure how I didn't see it a few weeks ago as it's 9
>>> weeks old.
>>> Who forgot to fill in the number?
>>>
>>> mod_deflate.c(1283) : warning C4003: not enough actual parameters for
>>> macro 'APLOGNO'
>>>
>>>  I just rechecked my compilation from near-trunk 6 hours ago, I don't see
>> this.
>>
>> More background, please?  gcc or other compiler rev?  OS?  Revision?
>>
>> It avoids a lot of needless speculation.
>>
>
> It's not a compiler thing, doesn't matter what OS. Sorry I didn't mention
> it's r1669555, my bad! You have the line number in the posted compiler
> output. However, it's pretty hard to miss as it's in the first stanza of
> the merge and practically hops in your lap.
>
>
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/filters/mod_deflate.c?r1=1661845&r2=1669555
>
>
>
>

Re: mod_deflate was Re: [VOTE] Release Apache httpd 2.4.13 as GA

[William A Rowe Jr]

On Thu, Jun 4, 2015 at 10:47 PM, Gregg Smith  wrote:

>
> This is new, not quite sure how I didn't see it a few weeks ago as it's 9
> weeks old.
> Who forgot to fill in the number?
>
> mod_deflate.c(1283) : warning C4003: not enough actual parameters for
> macro 'APLOGNO'
>

I just rechecked my compilation from near-trunk 6 hours ago, I don't see
this.

More background, please?  gcc or other compiler rev?  OS?  Revision?

It avoids a lot of needless speculation.

Re: T&R of 2.2.30 [corresponding to Re: T&R of 2.4.13]

[William A Rowe Jr]

Yes, thanks :)
On Jun 4, 2015 4:43 PM, "Rob Stradling"  wrote:

> s/2.2.13/2.2.30/
>
> ?
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>

Re: svn commit: r1683044 - /httpd/httpd/trunk/server/core.c

[William A Rowe Jr]

On Thu, Jun 4, 2015 at 1:23 PM, Marion & Christophe JAILLET <
christophe.jail...@wanadoo.fr> wrote:

>
> I agree that the wording of the Changelog could be more meaningful.
> Apparently these functions are only used during conf parsing. So, I propose
> to turn is into:
> "Small speed optimization when parsing  environment variables"
>

Yup, I agree.

Re: T&R of 2.2.13 [corresponding to Re: T&R of 2.4.13]

[William A Rowe Jr]

More context at your fingertips without refreshing httpd-2.2 branch,
first...

https://bz.apache.org/bugzilla/show_bug.cgi?id=57832

On Thu, Jun 4, 2015 at 11:26 AM, William A Rowe Jr 
wrote:

> [Changing subject, don't mean to hijack the 2.4 activity train]
>
> There is a modestly important patch, already backported to 2.4.x branch,
> that is still sitting in 2.2 status.  Could one more committer please
> review
> and vote on that remaining fix?
>
> Because it helps to avert an unintended doubled response in some edge
> cases, I consider this one important enough to hold up 2.2 tag for some
> more hours.
>
> Bill
>
>
> On Tue, Jun 2, 2015 at 4:36 PM, William A Rowe Jr 
> wrote:
>
>> On Tue, Jun 2, 2015 at 6:32 AM, Jim Jagielski  wrote:
>>
>>> Although there are some cool things that I'd like to see in
>>> 2.4.13, I don't want to hold off any longer (plus, those
>>> cool things would be good incentive for a 2.4.14 sooner
>>> rather than later).
>>>
>>> I plan to T&R 2.4.13 on Thurs, by Noon eastern.
>>>
>>
>> +1, planning to match you with a T&R of 2.2.30 on the same timetable.
>>
>> There is a nominally important last patch in 2.2 STATUS, if a third pair
>> of eyes have the cycles to review it.
>>
>
>

T&R of 2.2.13 [corresponding to Re: T&R of 2.4.13]

[William A Rowe Jr]

[Changing subject, don't mean to hijack the 2.4 activity train]

There is a modestly important patch, already backported to 2.4.x branch,
that is still sitting in 2.2 status.  Could one more committer please review
and vote on that remaining fix?

Because it helps to avert an unintended doubled response in some edge
cases, I consider this one important enough to hold up 2.2 tag for some
more hours.

Bill


On Tue, Jun 2, 2015 at 4:36 PM, William A Rowe Jr 
wrote:

> On Tue, Jun 2, 2015 at 6:32 AM, Jim Jagielski  wrote:
>
>> Although there are some cool things that I'd like to see in
>> 2.4.13, I don't want to hold off any longer (plus, those
>> cool things would be good incentive for a 2.4.14 sooner
>> rather than later).
>>
>> I plan to T&R 2.4.13 on Thurs, by Noon eastern.
>>
>
> +1, planning to match you with a T&R of 2.2.30 on the same timetable.
>
> There is a nominally important last patch in 2.2 STATUS, if a third pair
> of eyes have the cycles to review it.
>

Re: ALPN patch comments

[William A Rowe Jr]

On Wed, Jun 3, 2015 at 8:43 AM, Stefan Eissing  wrote:

> Hmm, personally, I do not like redundant configurations. If someone
> configures a module, like mod_h2, to be enabled (H2Engine on), she could
> expect the module to take all the necessary steps. So I am no fan of a
> „SSLAlpnEnable“.
>

The reason boils down to vhosts and interop.  If someone does not wish
for a specific vhost (perhaps interacting with bad clients, or created for
backwards compatibility) to respond with a feature, it is useful to have
a fine-grained toggle.  The default -could- be 'enabled', although this
probably should not happen on the stable/maintenance branches, but
simply on the future release branch, to avoid surprises.

OpenSSL does the wrong thing in some cases with respect to TLS/SNI
and my current patch development - in some respect - is backing out
that callback change for customers who have been burned by this
specific nonsense.  You should reconsider absolutist behaviors,
because they make it much harder for people to inject 'experimental'
behaviors into specific hosts.

Re: svn commit: r1683044 - /httpd/httpd/trunk/server/core.c

[William A Rowe Jr]

I tried to reconcile your patch with your svn log entry and I failed.
Could you either correct or explain further?

TIA,

Bill
On Jun 2, 2015 12:40 AM,  wrote:

> Author: jailletc36
> Date: Tue Jun  2 05:40:57 2015
> New Revision: 1683044
>
> URL: http://svn.apache.org/r1683044
> Log:
> Skip a few bytes before calling 'strchr' if we know that they can't match.
> s/apr_pstrndup/apr_pstrmemdup/ when applicable.
> Fix a comment typo.
>
> Modified:
> httpd/httpd/trunk/server/core.c
>
> Modified: httpd/httpd/trunk/server/core.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/core.c?rev=1683044&r1=1683043&r2=1683044&view=diff
>
> ==
> --- httpd/httpd/trunk/server/core.c (original)
> +++ httpd/httpd/trunk/server/core.c Tue Jun  2 05:40:57 2015
> @@ -1263,8 +1263,8 @@ AP_DECLARE(const char *) ap_resolve_env(
>  }
>
>  if (*s == '$') {
> -if (s[1] == '{' && (e = ap_strchr_c(s, '}'))) {
> -char *name = apr_pstrndup(p, s+2, e-s-2);
> +if (s[1] == '{' && (e = ap_strchr_c(s+2, '}'))) {
> +char *name = apr_pstrmemdup(p, s+2, e-s-2);
>  word = NULL;
>  if (server_config_defined_vars)
>  word = apr_table_get(server_config_defined_vars,
> name);
> @@ -2147,7 +2147,7 @@ AP_CORE_DECLARE_NONSTD(const char *) ap_
>  return unclosed_directive(cmd);
>  }
>
> -limited_methods = apr_pstrndup(cmd->temp_pool, arg, endp - arg);
> +limited_methods = apr_pstrmemdup(cmd->temp_pool, arg, endp - arg);
>
>  if (!limited_methods[0]) {
>  return missing_container_arg(cmd);
> @@ -2164,7 +2164,7 @@ AP_CORE_DECLARE_NONSTD(const char *) ap_
>  return "TRACE cannot be controlled by , see
> TraceEnable";
>  }
>  else if (methnum == M_INVALID) {
> -/* method has not been registered yet, but resorce restriction
> +/* method has not been registered yet, but resource
> restriction
>   * is always checked before method handling, so register it.
>   */
>  methnum = ap_method_register(cmd->pool,
>
>
>

Re: T&R of 2.4.13

[William A Rowe Jr]

On Tue, Jun 2, 2015 at 6:32 AM, Jim Jagielski  wrote:

> Although there are some cool things that I'd like to see in
> 2.4.13, I don't want to hold off any longer (plus, those
> cool things would be good incentive for a 2.4.14 sooner
> rather than later).
>
> I plan to T&R 2.4.13 on Thurs, by Noon eastern.
>

+1, planning to match you with a T&R of 2.2.30 on the same timetable.

There is a nominally important last patch in 2.2 STATUS, if a third pair of
eyes have the cycles to review it.

PMC Reporting [Was: Re: 2.2 and 2.4 and 2.6/3.0]

[William A Rowe Jr]

On Sat, May 30, 2015 at 2:14 PM, Daniel Ruggeri 
wrote:

> P.S.
> I'm not a Member or PMC... do I have access to the report that spurred
> the conversation?
>

Adding the context back to the thread...

On Wed, May 27, 2015 at 11:32 AM, Jim Jagielski  wrote:

> FWIW: It was this month's PMC status report which kind of
>   spurred this email.


Yes.  The Monthly Board of Directors meeting minutes do become public.
All of the following ASF documents are a matter of public record;

http://www.apache.org/foundation/records/

and you'll find the _Board Calendar and Minutes_ as the fifth link listed on
that page.  Following through to the minutes, as of this moment, minutes
are only current up to March, several months ago, but that is because they
are reviewed by any officer attending and all board board member for errors
and omissions before they are approved at a subsequent meeting.  So this
will be 1-90 days out of sync, occasionally longer.

As far as our report submitted to the board each quarter - and included in
the foundation board minutes, the last published already was Feb '15, so
the subsequent one is last month, May '15 and should show up in another
month or two.  In theory, it isn't our report until 1. it is submitted, the
board
2. considers and 3. accepts the report at their meeting (a few weeks ago),
and 4. accepts the minutes of their meeting as recorded :)

So I'll let Eric share what he submitted for May on our behalf, but here
is the submitted/accepted/recorded report of Feb '15 - it's awfully high
level, so I'm not sure that updating dev@ regularly with the contents
offers a whole lot of benefit.  Thoughts?

Attachment AL: Report from the Apache HTTP Server Project  [Eric Covener]

Project Description
===
The Apache HTTP Server Project develops and maintains an
open-source HTTP server for modern operating systems.

Issues for the Board

There are no outstanding issues that require the board's attention.

Releases


  * 2.4.12 : Released on January 29, 2014

  Older branches last release:

* 2.2.x:   2.2.29 released September 3 2014
* 2.0.x(EOL)   2.0.65 released July 9, 2013

Bug Activity


  * 164 bugs worked on, 60 new, 71 closed/fixed

Community
=

  * Yann Ylavic was added to the PMC.
  * Date of last new committer : October 2014 (Steve Hay)
  * Date of last new PMC member: February 2015 (Yann Ylavic)

  * Overall development activity continues to slow, with the focus on
security fixes andthe maintenance of 2.4.x which is making its way
into various httpd distributions.

  * Thanks to Rich Bowen for organizing a httpd/TS/Tomcat track for ACNA 2015.

Re: Good at assembler ? (Was:httpd - side channel attack - timing of digest comparisons)

[William A Rowe Jr]

> Secondly - when we get to the end of the shorter string; we can either
keep comparing to the last char or \0; or we go ‘modulo’ to the start of
the string. Now modulo is perhaps not ideal; and seems to affect the
pipeline on the XEON cpu (something I confess not to quite understand; and
I cannot see/replicate on ARM).

Comparing the same byte is easily optimized out.

What about looping over the same 16-byte micro-page we ended with, to avoid
fetching much earlier pages?  Truncate the address by nulling pointer bits
0x0f ?

Re: httpd and OpenSSL 1.0.2

[William A Rowe Jr]

Don't be fooled.

OpenSSL 1.0.1 did not break binary compatibility, the lib designation
remains .so.1.0.0.  Can someone confirm whether this was changed in 1.0.2?
On May 29, 2015 10:26 AM, "Mario Brandt"  wrote:

> Hi Andy,
>
> it seems that you are right. After cheking the lib I saw this
>
> -rw-r--r--  1 root root 4,4M Mai 29 10:51 libcrypto.a
> lrwxrwxrwx  1 root root   18 Mai 29 10:51 libcrypto.so ->
> libcrypto.so.1.0.0
> -r-xr-xr-x  1 root root 2,6M Mai 29 10:51 libcrypto.so.1.0.0
> -rw-r--r--  1 root root 744K Mai 29 10:51 libssl.a
> lrwxrwxrwx  1 root root   15 Mai 29 10:51 libssl.so -> libssl.so.1.0.0
> -r-xr-xr-x  1 root root 499K Mai 29 10:51 libssl.so.1.0.0
>
> that shows the current date, but the old version number.
>
> Mario
>
> On 29 May 2015 at 15:16, Wang, Andy  wrote:
> > You might want to reconsider that unless you really really are sure you
> know what you're doing.
> > On a linux distro, the system installed openssl is considered a
> fundamental platform infrastructure library.  I.e. many many things rely on
> it.  openssl versions are not backward compatible.
> >
> > So if you don't rebuild all of your distro installed dependencies on
> openssl, you've likedly just screwed up runtime linking of alot of things.
> >
> > Also, the system installed library and the openssl config makefiles may
> be using incompatible soname mechanisms, which could explain why you're
> able to link but not run (i.e. at linktime it may be finding the right
> library, but at runtime it's not).
> >
> > Andy
> >
> > 
> > From: Mario Brandt [jbl...@gmail.com]
> > Sent: Friday, May 29, 2015 3:57 AM
> > To: Tom Browder
> > Cc: dev@httpd.apache.org
> > Subject: Re: httpd and OpenSSL 1.0.2
> >
> > Hi Tom,
> >
> > nope setting LD_LIBRARY_PATH did not solve my problem. That is a bit
> > tricky since I install the new openssl version system wide
> >
> > ./config --prefix=/usr zlib-dynamic --openssldir=/etc/ssl shared no-ssl2
> >
> >
> > Mario
> >
> >> -Tom
>

Re: [VOTE] Simplified 2.2.x EOL Decision

[William A Rowe Jr]

On May 28, 2015 5:31 AM, "Jim Jagielski"  wrote:
>
> Why just 2 options and why *these* 2?
>
> The VOTE is worthless and obviously designed to stop discussion.
> I am not voting.

By all means then, don't.

To answer your question, these are the only two directions the project has
taken over the last 15 years, as I documented this afternoon.
Counterexamples would be welcome.

This conversation reoccurs consistently with the same two opposing agendas;
1. Prevent committers from burning cycles on old branches, vs. 2. Support
old branches while they are widely deployed.  The many threads you can read
in our archives follow the same pattern each time.  In general, Jeff's much
more diplomatic answer becomes the consensus, and the project moves on.

To answer your more detailed question;

> > On May 28, 2015, at 12:44 AM, William A Rowe Jr 
wrote:
> >
> > Choose one;
> >
> > [ ] EOL the 2.2.x branch effective 5/31/16; strictly security releases
to that date

This 12 month window seems to have universal consensus from the email
archives, once a consensus is reached.  Other numbers are often mentioned,
and it always boils back down to a year.

> > [ ] Defer a 2.2.x EOL decision for 6 months and re-consider this
proposal in Nov, '15.

This too is the typical window for revisiting cold threads (actually, more
like 6-18/mos, so I picked the short end of that range).  Your particular
post was a month after the question was asked and answered and (notably)
not contradicted.  If there was disagreement there was a perfectly valid
thread to resume and debate the particulars of either a prompt EOL or a
longer window of time.

Your top-post clearly advocated for the first choice, but perhaps was
incomplete?  I am very receptive to the details you left out of that top
post, that would have offered us a third-way that none of us expected, if
only you had the free cycles the other morning to flesh out that unique
proposal. Sincerely, please suggest something we haven't considered before,
otherwise this is the same old same old again.

Re: Measurement - Jeff's metric [was: [VOTE] Simplified 2.2.x EOL Decision]

[William A Rowe Jr]

On May 28, 2015 8:38 AM, "Yann Ylavic"  wrote:
>
> On Thu, May 28, 2015 at 9:32 AM, William A Rowe Jr 
wrote:
> > On Thu, May 28, 2015 at 2:22 AM, Yann Ylavic 
wrote:
> >>
> >>
> >> I think I would have preferred Jeff's form of the vote, which would
> >> have allowed us to know the potential "operating forces" on 2.2.x.
> >
> >
> > We determined from that poll that there were >3 committers who
> > would fix bugs on 2.2, so that discussion was already done.
>
> That was an informal poll, whereas an official one would probably have
> allowed us to count ourselves and maybe see if we can still maintain
> 2.2 effectively.

The project's definition... no, the ASF definition of effective
participants -is- 3 :)

I've packed it in when code bases no longer had that number of
participants.  E.g. the 1.3/2.0 EOL was by unanimous consensus, retiring
mod_aspdotnet was by unanimous consensus.  The mod_arm4 code should likely
also be retired, I wouldn't anticipate an objection.

Where 1 or 2 individuals want an effort to persist at the ASF, and cannot
find a third hand, that is a sad outcome, but hasn't happened at httpd that
I recall.  It is unlikely to be the case here, either.

> Speeking for myself, if the cost of using (hence backporting to) 2.2.x
> exceeds significantly the one
> (technical/political/educational/whatever-al) of upgrading to 2.4.x,
> I'll choose the latter...
> ISTM that it's also a question of workforce, not that I doubt about
> committers wrt 2.2.x, I just wish I had a better idea with that poll
> (>3 is nice to know, but so is  >> Sure people like having their release maintained, for free is even
> >> better,
> >
> > They like having their new releases for free even more-so.  What
> > inspired you to call out 'free' as in cash-in-lieu-of-beer?
>
> I meant free of time, work, or elbow/finger grease ;)

(:  thanks for clarifying.

> >> the investment is done either by the committers (for all
> >> living versions) or the users (upgrading).
> >
> > No, it's not an either-or proposition.  Committers, for those who
> > aren't in a position to upgrade (and only those who maintain an
> > interest, e.g. those >3 who responded to Jeff's survey).  And the
> > users who are stuck in an update trajectory, for the time being,
> > or who have the freedom to upgrade (preferably, their entire host
> > or container OS).
>
> Well, some (maybe most, but not all!) won't move unless/until they
> face a missing security/bug fix in 2.2.x.
> Why would they if they don't need a new feature, and why will they in
> 1/2/3.. years?

Why indeed.  Hopefully we offer compelling reasons.  I'm much more
concerned to help people avoid provisioning an old crufty version such as
2.2.30 versus adopting 2.4.13 from the get-go.  Whatever we can do to help
with that aught to be welcomed by the user community.

Thanks for your thoughts.

Re: 2.2 and 2.4 and 2.6/3.0

[William A Rowe Jr]

On May 27, 2015 9:46 AM, "Jeff Trawick"  wrote:
>
> On Wed, May 27, 2015 at 10:42 AM, Jeff Trawick  wrote:
>>
>> On Wed, May 27, 2015 at 8:54 AM, Jim Jagielski  wrote:
>>>
>>> Anyone else think it's time to EOL 2.2 and focus
>>> on 2.4 and the next gen? My thoughts are that http/2
>>> and mod_h2 will drive the trunk design efforts and so
>>> it would be nice to focus energy on 2.4 and later...
>>
>> People here focus their energy on whatever they want.  It takes a small
number of people to keep a stable branch going (technically 3, but in
practice a slightly higher number).  Instead of the group choosing EOL or
only-security-fixes-of-some-minimal-severity or something else for a stable
branch based on what many people think is interesting to them for whatever
reason, I think that the project should limit its concern to ensuring that
the community understands the state of the branch and that it is EOL-ed
when a sufficient number of people don't care.
>
> actually, "when a sufficient number of people don't care" is what I'm
arguing against :)  make that "when an insufficient number of people care"

+1, well thought out, aligns with the historical commentary (just some of
which I pointed out in the historical data points post)

>> What we need to know for the 2.2.x branch is basically this:
>>
>> Developers (committers or not):
>>
>> [ X ] I am willing to help resolve security issues in the 2.2.x branch.
>> [ X ] I am willing to help address non-security issues in the 2.2.x
branch.
>>
>> PMC members:
>>
>> [ X ] I am willing to test and vote on proposed 2.2.x releases.

>> (This is not a call for vote; I'm suggesting a very different mindset
towards 2.2.x from "nice to focus energy on" and "time to EOL 2.2 and focus
on".)

(:  Glad that others felt free to respond to this as a poll.

Re: 2.2 and 2.4 and 2.6/3.0

[William A Rowe Jr]

More data points and history to ponder, with placeholders to reflect the
passage of time;

1998-06-06 Initial 1.3.0  Release
1999-03-24 Stable 1.3.6 Release (last major MMN bump)
2000
2001
2002-04-05 Initial 2.0.35 Release
2002-09-24 Stable 2.0.42 Release (last major MMN bump)
2003
2004
2005-12-01 Initial 2.2.0  Release
2006
2007
2008
2009
2010-02-02 Final 1.3.42 Release
2011-02-02 End of 1.3.xx Life (security patches)
2012-02-21 Initial 2.4.1  Release
2013-02-21 End of 2.0.xx Life (originally planned)
2013-07-09 Final 2.0.65 Release, true EOL
2014
-??-?? Initial 2.6.0/3.0.0 Release
-??-?? Final   2.2.?? Release

1.3 Lifespan; ~11 Years - ~8 Years overlap w/ 2.0 (+1 year of security
attention/patches)

2.0 Lifespan; ~11 Years - ~8 Years overlap w/ 2.2

2.2 Current clock 9 1/2 years, ~3 Years overlap w/ 2.4

Largest difference?  2.4 arrived 3 years later than the 2.0, 2.2 cadence.

Nov 2004 discussion of an EOL Policy for 2.0;
http://markmail.org/message/sbddhnoxnz36howj?q=+end+of+life+httpd+1%2E3+list:org%2Eapache%2Ehttpd%2Edev&page=3

State of the 1.3 ecosystem when voting to deprecate in Jan 2010;
http://markmail.org/message/z34jplaw2vk2mfsk?q=end+of+life+httpd+1%2E3+list:org%2Eapache%2Ehttpd%2Edev

Discussion of the EOL of 2.0 in Sept 2011;
http://markmail.org/message/hyf72mrrgggjk4ij?q=apache+httpd+2%2E0+end+of+life

The 1.3.42 Announcement/EOL statement
http://markmail.org/message/her5q6wcmvvv42tr?q=apache+httpd+1%2E3%2E42+announce

The 2.0.65 Announcement/EOL statement;
http://markmail.org/message/kkgtum56qfqi6xix?q=apache+httpd+2%2E0%2E65+announce

On Thu, May 28, 2015 at 1:25 PM, Houser, Rick 
wrote:

> Mageia:
>
> Mageia 3 released with Apahe 2.4 in April 2013
> Apache 2.2 (via Mageia 2) reached EOL in November 2013
>

Re: httpd - side channel attack - timing of digest comparisons

[William A Rowe Jr]

On May 26, 2015 10:31 AM, "Dirk-Willem van Gulik" 
wrote:
>
>
> > On 26 May 2015, at 17:22, Dirk-Willem van Gulik 
wrote:
> ..
> > So I think that what is needed are two (or three) functions
> ...
> > - A string comparison function; where at least one string is is
under control of the attacker.
>
> Now the issue here is that length is every easily revealed. So I can
think of 2 strategies;
>
> -   firmly declare (in the signature of the compare function) one
argument as potentially hostile.
>
> And do the comparison largely based on that; which means we only
marginally reveal the
> actual length of the string compared to. Below is an example; but
my gut feel it is not
> nearly good enough when you can apply a large chunk of statistics
against it.
>
> -   treat them both as hostile; and scan for either the shortest or
longest one and accept
> that you leak something about length.
>
> Or - if needed - pad this out for strings <1024 (or similar)
chars in length by doing always
> that many (which will leak less).
>
> Examples are below. Suggestions appreciated.
>
> Dw.
>
> static int or_bits(int  x) {
>   x |= (x >> 4);
>   x |= (x >> 2);
>   x |= (x >> 1);
>   return -(x & 1);
> }
>
> /* Quick mickey mouse version to compare the strings. XXX fixme.
>  */
> AP_DECLARE(int) ap_timingsafe_strcmp(const char * hostile_string, const
char * to_protect__string) {
> const unsigned char *p1 = (const unsigned char *)hostile_string;
> const unsigned char *p2 = (const unsigned char
*)to_protect__string;
> size_t i = 0, i1 = 0 ,i2 = 0;
> unsigned int res = 0;
> unsigned int d1, d2;
>
> do {
> res |= or_bits(p1[i1] - p2[i2]);
>
> d1 = -or_bits(p1[i1]);
> d2 = -or_bits(p2[i2]);
>
> i1 += d1;
> i2 += d2;
> i += (d1 | d2);
>
> #icase A
> } while (d1 | d2); // longest one will abort
> #case B
> } while (d1 & d2); // shortest one will abort
> #case C
> } while (i < 1024) } while (d1 | d2); // at least 1024 or longest
one/shortest one
>
> // include the length in the coparision; as to avoid foo v.s.
foofoofoo to match.
> //
> return (int) (res | ( i1 - i2));
> }

Giving this some thought for the string version, does it make sense to loop
the underflow string back to offset zero on EOS?  There is a certain amount
of cache avoidance that could cause, but it would dodge the optimization of
that phase and ensure the longest-match comparisons are performed (measured
by the untrusted input, presumably).

Ad-hominem [was: [VOTE] Simplified 2.2.x EOL Decision]

[William A Rowe Jr]

On Thu, May 28, 2015 at 2:48 AM, Noel Butler  wrote:

> On 28/05/2015 14:48, William A Rowe Jr wrote:
>
>   Enough of this ad-hominem BS... [...]
>
>
> You've lost the argument and lost respect, you have demonstrated that by
> this pathetic and childish response. Just because others have a different
> opinion to you, does NOT make them a troll William, nor does warrant your
> bordering on bullying immature response, when you grow up and become an
> adult again, I'll take your concerns seriously.
>
Noel,

Frankly, I don't care whether you take my concerns seriously or not, that
is irrelevant.

If you have a vote, please vote [changed subject, your reply didn't belong
on a vote thread without casting a vote - find the top-post.]  I and all
PMC members will respect your vote, and each of our peers' votes.

Indeed, if you are continuing to chiding me and other committers for not
doing what you would have us do, you are indeed a troll.  If you are asking
whether or not you can focus your efforts on 2.4, nobody has been blocking
you from doing so, exclusively.  If you are imposing your direction upon
fellow committers, and then mocking them for their interests other than
your own, than you sir, really, truly are the troll.

But if that is not what you or others meant to imply, of course I would
retract that unjustified characterization!

Yours sincerely,

Bill

Measurement - Jeff's metric [was: [VOTE] Simplified 2.2.x EOL Decision]

[William A Rowe Jr]

On Thu, May 28, 2015 at 2:22 AM, Yann Ylavic  wrote:

>
> I think I would have preferred Jeff's form of the vote, which would
> have allowed us to know the potential "operating forces" on 2.2.x.
>

We determined from that poll that there were >3 committers who
would fix bugs on 2.2, so that discussion was already done.  Sadly
this was ignored by Noel deciding to 'pile on'.  I really hope nobody
piles on to anything other than their own interests in contributing
to this project.  That should be devoid of persons and personalities.


> Sure people like having their release maintained, for free is even
> better,


They like having their new releases for free even more-so.  What
inspired you to call out 'free' as in cash-in-lieu-of-beer?


> the investment is done either by the committers (for all
> living versions) or the users (upgrading).
>

No, it's not an either-or proposition.  Committers, for those who
aren't in a position to upgrade (and only those who maintain an
interest, e.g. those >3 who responded to Jeff's survey).  And the
users who are stuck in an update trajectory, for the time being,
or who have the freedom to upgrade (preferably, their entire host
or container OS).

Re: 2.2 and 2.4 and 2.6/3.0

[William A Rowe Jr]

On Wed, May 27, 2015 at 1:41 PM, William A Rowe Jr 
wrote:

>
> Ubuntu - 14.04 LTS, and Debian 8 (Jessie) got the message, a year ago
> April.
>
> RHEL / CentOS 7 aren't even a year old yet.
>
> OpenSUSE 13.1 beat them all to the punch, back in Nov of '13.  So that's
> the oldest distribution GA that I've found, perhaps Fedora beat that?
>

To round out, but by no means complete this survey, Fedora 18 shipped
1-15-13, so it in fact beat OpenSuSE GA by 10 months (if you consider a
fedora release a 'release' - shrug).

Re: [VOTE] Simplified 2.2.x EOL Decision

[William A Rowe Jr]

On Wed, May 27, 2015 at 11:44 PM, William A Rowe Jr 
wrote:

> Choose one;
>
> [ ] EOL the 2.2.x branch effective 5/31/16; strictly security releases to
> that date
> [X] Defer a 2.2.x EOL decision for 6 months and re-consider this proposal
> in Nov, '15.
>

Enough of this ad-hominem BS... this is in fact a majority rule decision
(it is a vote
not on code but on procedure), and is binding on the project as a whole.  I
don't
want to discuss this again for six months and I'm not keen on the smug
little
trolls telling me what I should and should not be working on at a project
that
I participate at.

[VOTE] Simplified 2.2.x EOL Decision

[William A Rowe Jr]

Choose one;

[ ] EOL the 2.2.x branch effective 5/31/16; strictly security releases to
that date
[ ] Defer a 2.2.x EOL decision for 6 months and re-consider this proposal
in Nov, '15.

Re: 2.2 and 2.4 and 2.6/3.0

[William A Rowe Jr]

On Wed, May 27, 2015 at 6:59 PM, Noel Butler  wrote:

> On 28/05/2015 03:17, Jim Jagielski wrote:
>
> [...] maybe it's time to say that 2.2's era is done, and
> 2.4's time is here, if not already past. I'm simply trying
> to encourage us to work on the future and not "focus" on
> the past. No need to read anything more into that [...]
>
> My apologies if "Anyone else think it's time to EOL 2.2 and focus
> on 2.4 and the next gen?" was such an egregious question!
> Shame on me for even asking! :)
>
>
> From the responses I got when I mentioned EOL 2.2 in a discussion a few
> months back, it was very clear a few here enjoy living in the dark ages and
> were most passionate about staying there for the time being :)
>

Or, a few here care about the users stuck in the situation of using the
software in front of them, instead of dovetailing sideways against the
current to build themselves a package that isn't in their distribution's
repository.  A few of us are very focused on the actual users using the
actual software they were presented with.

Hopefully, in a few years time, nobody will ever again be presented with
2.2, or 2.0, or 1.3.  Given the most-common 3-year refresh cycle followed
in our industry, that would mean about a year-and-a-half from now for SuSE
users, and more than two years from now for the poor RHEL and CentOS users.

Re: 2.2 and 2.4 and 2.6/3.0

[William A Rowe Jr]

On Wed, May 27, 2015 at 12:17 PM, Jim Jagielski  wrote:

> No need to go off...


Did I?


> 2.2 has been out for almost 10 years.
>

Irrelevant to the discussion...


> 2.4 for a bit over 3. That is a LONG time.


Specifically, http://svn.apache.org/r1243503

Generally unusable, the next several versions fixed the serious regressions
and we had a pretty solid release by 2.4.3/2.4.4 timetable (about 2 1/2
years ago).

Given the lag between a release, incorporating it into an alpha of a
distribution release, and that distribution going GA, that is a long lag.

Ubuntu - 14.04 LTS, and Debian 8 (Jessie) got the message, a year ago April.

RHEL / CentOS 7 aren't even a year old yet.

OpenSUSE 13.1 beat them all to the punch, back in Nov of '13.  So that's
the oldest distribution GA that I've found, perhaps Fedora beat that?

So your 'over 3 years' is a pretty gross exaggeration if you are speaking
of "users" as people who get httpd from their OS distribution.


> I'm simply
> *suggesting* (no BDFL posturing Mr. Rowe) that after 10
> years, maybe it's time to say that 2.2's era is done, and
> 2.4's time is here, if not already past.


And the empirical data says, nope.  Nearly 80% of installed httpd is still
2.2.  RedHat and the others all have years ahead supporting httpd-2.2.

Your suggestion is duly noted and filed :)


> I'm simply trying
> to encourage us to work on the future and not "focus" on
> the past. No need to read anything more into that, or
> take on a onerous or holier-than-thou tone.
>

By which your message might be perceived as taking a holier-than-thou
tone.  Since neither of us would do that, let's move on :)

So folks (who don't build themselves) have only had 11 - 18 months to start
picking up httpd 2.4, that doesn't seem like the distant past to me, and
seems like forever ago to you, that's fine.  We are an association of peers
with different interests and responsibilities, and have different
perspectives on our end user communities.

Everything we can do to help them move forward is great.  If the insist on
running httpd 2.4 on Ubuntu 12.04-LTS or RHEL 5, well... the wiki
especially could offer help with that.  There are already per-architecture
notes and wiki pages.  Hopefully they adopt a modern operating system and
modern releases of Apache projects across the board.

My apologies if "Anyone else think it's time to EOL 2.2 and focus
> on 2.4 and the next gen?" was such an egregious question!
> Shame on me for even asking! :)


Ask away!  Below was the discussion result last month.  I'd expect this to
be brought up monthly until "maintainers" get bored with the dialog and an
EOL is pushed through :)


On Thu, Apr 2, 2015 at 4:52 PM, William A. Rowe Jr. 
 wrote:

> On Fri, 13 Mar 2015 08:28:35 +1000
> Noel Butler  wrote:
> >
> > Time to think about EOL'ing 2.2 maybe since its 10 years old and 2.4
> > has been current stable best production recommendation for what,
> > about 3.5 years or so now, that would see adoption rates grow ;)
>
> That would be altogether reasonable, if the currently adopted and still
> widely supported operating systems shipped 2.4, but it isn't so.  While
> the adoption of 2.2 is all tied into current operating systems, we
> aren't about to forego security patches to such widely used code.
>
> Something to rethink when 2.4 starts to seriously catch up and surpass
> the 2.2 deployments.
>
> The EOL of 2.2 will occur, just as with 2.0, and with 1.3, when you can
> no longer find a subset of the httpd project members and committers to
> do any maintenance for the branch.  I'm guessing that the inflection
> point is much closer to 2 years away than 12 months from now.
>
>

Re: 2.2 and 2.4 and 2.6/3.0

[William A Rowe Jr]

On Wed, May 27, 2015 at 11:33 AM, Jim Jagielski  wrote:

> >
> > Focus your energy on anything you like.
> >
>
> Can't grok whether that's snarky or not... I'll assume not :)
>

Please assume not :)  ASF projects should still remain
scratch-your-own-itch(es).

Your message certainly had an 'adopt my agenda' tone to it, but I similarly
didn't assume this was belligerent :)

On Wed, May 27, 2015 at 11:32 AM, Jim Jagielski  wrote:

> My point is that if we EOL 2.2 (with some definition of "EOL")
> then people on 2.2 (or earlier) will have some *real* incentive
> to move off of 2.2 towards 2.4 (or later)...
>

Define "people".  The overwhelming majority of "people" use whatever is
distributed with their OS.

If your "people" are the distributors, just surveying current and
immediately forthcoming distributions, it seems the message got through
loud and clear.

Basically, we need something to "kick" people off 2.2
> and get them to 2.4.


We've always used the 1 year yardstick, and from the graphs and
distribution EOL's, 1 year is too soon.

At the Tomcat project they generally support 3 major/minor releases in
parallel.  Here, our support has oscillated between 2 and 3 releases since
2.0.36.  A new minor release has usually been the trigger to EOL the 3rd
oldest release.  In the real-world, we won't hit a point where there is
only one major/minor release is wide use, not unless we slow the pace of
major/minor releases to once every ten years ... not a goal to aspire to.

By stating that 2.2 will ONLY get
> security related fixes and no new features or improvements,
> and that 2.2 will be EOL by 201X, that will be encouragement.
>

It should be readily apparent from CHANGES for 2.2 and 2.4 which gets more
attention.  All of our announcements clarify that 2.4.new is the latest and
greatest.

If there are three PMC folks who want a bug fixed in 2.2, what is your
point in establishing an agenda against that fix?  In a BDFL project, that
posturing is expected.

Clearly there are very few bug fixes that attract developer's attention on
2.2 anymore.  A better and perhaps less offensive question might be; how do
we, as a project, communicate how legacy the legacy release really is?

That, of course, assumes that we "care" one way or another
> about moving people to a more up-to-date and performant
> httpd, as well as whatever the future holds for httpd.


Is there a reason you imply that contributors at this project don't seek
this?  The only divisions I see on the horizon are gaining consensus on the
scope of any radical changes between 2.4.x and httpd-next.

Re: SSL/TLS best current practice

[William A Rowe Jr]

On Tue, May 26, 2015 at 11:45 AM, Andy Wang  wrote:

>
> On 05/26/2015 11:25 AM, William A Rowe Jr wrote:
>
>> On Tue, May 26, 2015 at 10:45 AM, Yann Ylavic > <mailto:ylavic@gmail.com>> wrote:
>>
>> On Tue, May 26, 2015 at 5:29 PM, Andy Wang > <mailto:aw...@ptc.com>> wrote:
>>  >
>>  >> #   SSL Cipher Suite:
>>  >> #   List the ciphers that the client is permitted to negotiate.
>>  >> #   See the mod_ssl documentation for a complete list.
>>  >> SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4
>>  >> SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4
>>  >
>>  > !aNULL isn't needed?
>>
>> No since !aNULL:!eNULL:!EXP is forcibly added to the configured
>> ciphersuite.
>>
>>
>> A legitimate question, however.  The example should document this IMHO.
>> Getting right on that.
>>
>>
> I initially thought openssl disabled the NULL ones by default but when i
> started playing with openssl cipher strings and saw them I got confused.
> Didn't even consider that httpd did it automatically.  Documenting it would
> be a nice touch. Thanks for doing that.
>

As it turns out, 0.9.2b disabled aNULL/eNULL by default.  Export ciphers
are disabled by default as of 0.9.8zf/1.0.0r/1.0.1m/1.0.2a.

Here's my proposed comment to inject in trunk/2.4/2.2 default
httpd-ssl.conf - any adjustments here?

# httpd 2.2.30, 2.4.13 and later force-disable aNULL, eNULL and EXP ciphers,
# while OpenSSL disabled these by default in 0.9.8zf/1.0.0r/1.0.1m/1.0.2a.

Re: 2.2 and 2.4 and 2.6/3.0

[William A Rowe Jr]

On Wed, May 27, 2015 at 7:54 AM, Jim Jagielski  wrote:

> Anyone else think it's time to EOL 2.2 and focus
> on 2.4 and the next gen?


Nope, we'll let the internet speak for itself -

http://w3techs.com/technologies/history_details/ws-apache/2

We are nowhere near close enough to the inflection point of that graph to
justify starting the 12 month EOL clock (which has been our traditional
countdown, same as the Tomcat project).

My thoughts are that http/2
> and mod_h2 will drive the trunk design efforts and so
>

That sounds about right.  I'm personally interested in 3.0 - refactoring on
trunk to clean up the evolution of httpd since 2.0.36.  That was when we
froze MMN majors, so many many bits are now shoehorned into the server in
very awkward manners.  This will make backports to 2.4 more complex,
however.


> it would be nice to focus energy on 2.4 and later...
>

Focus your energy on anything you like.

Re: SSL/TLS best current practice

[William A Rowe Jr]

On Tue, May 26, 2015 at 10:45 AM, Yann Ylavic  wrote:

> On Tue, May 26, 2015 at 5:29 PM, Andy Wang  wrote:
> >
> >> #   SSL Cipher Suite:
> >> #   List the ciphers that the client is permitted to negotiate.
> >> #   See the mod_ssl documentation for a complete list.
> >> SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4
> >> SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4
> >
> > !aNULL isn't needed?
>
> No since !aNULL:!eNULL:!EXP is forcibly added to the configured
> ciphersuite.
>

A legitimate question, however.  The example should document this IMHO.
Getting right on that.