Re: backports
On Sat, Mar 5, 2022, 11:47 AM Jim Jagielski wrote: > > That's where I was heading with this, so I'm an obvious +1 to switching to > making > a Github-based workflow "official" for the PMC. +1 --Jacob
Re: iOS 14 / macOS 11 and HTTP/3 support
On Mon, Jun 29, 2020 at 1:17 AM Stefan Eissing wrote: > 2. Redesign a FOSS httpd v3.x with a new architecture, embracing a > non-blocking processing model. Maybe under a different name. Is there widespread interest in this approach (option 2)? It's, in theory, my preference -- I get the feeling, viewing from the outside, that the mod_h2 architectural work was incredibly painful due to the mismatch between what httpd provides and what was needed. Option 1 doesn't feel like a good long-term strategy. Re: the SSL library problems, does anyone know if mod_nss is a stable enough thing to begin building off of? --Jacob
Re: Experimental C unit test suite available for hacking
On 05/23/2018 10:32 AM, Marion et Christophe JAILLET wrote: > '--with-test-suite=...' is for the Perl test framework, not for the > 'test/httpdunit'. Ah, yes! Thanks for the reminder; --with-test-suite only enables the `make check` functionality. Sorry, it's been too long. On 05/23/2018 01:21 PM, Christophe Jaillet wrote: I can reproduce the issue if I don't pass any --enable-mpms-shared paramater to ./configure. Me too. The problem, I think, is that the $(MPM_LIB) depends on symbols in server/libmain.la, but comes after it in the $(PROGRAM_DEPENDENCIES). That won't work. Moving $(MPM_LIB) up above server/libmain.la in the top-level Makefile.in seems to solve the problem for me, but I'm not able to sufficiently test tonight to make sure it doesn't break something else. HTH? --Jacob
Re: Experimental C unit test suite available for hacking
On Wed, May 23, 2018, 7:35 AM Micha Lenk wrote: > > It should only get built if you configure --with-test-suite=... and > > specify the path to a perl-framework wc. It builds for me in trunk. > > Hmm, no difference. It seems to get built independent from whether you > specify --with-test-suite or not. As a cross check I've just added > "--with-test-suite=../httpd-test" to the configure flags, but I still > get the same build failure. > Hi Micha, thanks for your interest! I won't be able to debug into this until later in the day, but I'll try to take a look. You asked about buildbot -- IIRC, several pieces of the test suite don't run there, but it's been months since I last looked. --Jacob >
Re: We have soon 5 SVN repo's
On Nov 4, 2017 8:44 PM, "William A Rowe Jr" wrote: >> Will it be a fork of latest 2.4.x and trunk things will have to be >> proposed, voted and backported? That is not how httpd has operated previously. Again, a proposal to change the process and a vote is needed if this is desired. Time for a vote I think. --Jacob
Re: Thoughts on 2.5.0
On 10/24/2017 11:45 AM, William A Rowe Jr wrote: On Tue, Oct 24, 2017 at 12:35 PM, Jim Jagielski wrote: That is way when we backport we transition to RTC, because we want to ENSURE it's been reviewed. Wrong. I was there. RTC was adopted in order to ensure both the reliability but moreso, the compatibility of changes during a given x.y major/minor release cycle. CTR existed to make forward progress and get out of our developers' way. I'm not really sure Jim's statement here is "wrong". Regardless of historical context. We use RTC when we want to guarantee review. You are suggesting a change of policy. It is not policy to use RTC to get from trunk to 2.6.0, and will not become policy without a vote for such a change by the PMC. I'm not entirely convinced Jim is suggesting a change in policy, as you say. But in any case, I would be +1 to such a change. We should not be releasing a 2.6.x that contains unreviewed code. --Jacob
Re: trunk-md merge pending
On 08/08/2017 07:19 AM, Stefan Eissing wrote: PS. @Jchampion: I am not sure how to best merge the unit test cases into httpd. They need to be optional, tied to the availability of mod_md and I do not know how to do that. I need to solve this problem for another module as well (mod_auth_digest has a regression unit test case), but I haven't decided how to tackle it yet. PPS. Another nit: mod_md also builds an executable, currently named a2md. I thought about putting it in support/, but since this depends upon the optional mod_md, it is more natural in modules/md, I thought. I don't think having an optional support executable would be a bad thing. That said, I don't have strong opinions either way. FYI I'll be somewhat inactive here on dev@ for a couple of weeks as I adjust to a new job, so don't be afraid to ping me multiple times if you need me. :D --Jacob
Re: SSLPolicy
On 08/04/2017 04:38 AM, Luca Toscano wrote: I agree that mod_macro is flexible enough to improve the reusability of httpd's configuration, but I don't think that the goals that Stefan has in mind are satisfiable with your proposed solution. If we find ourselves doing more of this syntactic sugar stuff -- grouping related directives into meta-directives -- I think it'd be nice to extend mod_macro to the point that we can build those meta-directives using its functionality directly, and then fold that into core. For now, though, I'm ++1 to Stefan's concept. We can see how much extra/duplicate code there is and try to refactor it up as we go. --Jacob
Re: svn commit: r1803072 - /httpd/site/trunk/content/security/vulnerabilities-httpd.page/securitydb.xsl
On 07/26/2017 04:15 PM, William A. Rowe Jr. wrote: Yup, thanks for the follow-up! Site is updated and links to security_vuln24.html#CVE-2017- will now resolve to a sensible place on our vuln lists. Thanks for this addition; it's already made navigation much easier for me. Firefox was complaining about the anchor, and it looks like HTML5 has deprecated that construct entirely, so I followed up with r1803232. From what I can see, the "new" technique is supported even by much older browsers, but I want to make sure it still works for you before pushing it live. --Jacob
Re: svn commit: r1802336 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml
On 07/24/2017 01:03 PM, Yann Ylavic wrote: What if the fpm queue in ap_proxy_connect_backend or at POLLOUT time? If both cases I think the socket is not reused by mod_proxy_fcgi for the next request, so I don't see how it's a enablereuse issue... I'm not sure I understand your question, but I think I've described the problem incompletely. Let me give it another try: Let's say FPM has been configured to handle 5 concurrent connections, and httpd has been configured to use up to 10. With connection reuse disabled, if we hit the server with ten requests to FPM, five connections will be served immediately, and FPM will queue up the next five. As requests finish, httpd closes each connection, and FPM grabs the next connection to service. Everything works. With connection reuse enabled, FPM still queues the last five connections. But because httpd never releases the first five, and new incoming requests continue to use them, those queued connections never get serviced. That's not FPM's fault; it advertises how many concurrent connections it can handle via the FCGI protocol, and if it refused those queued connections by default, our first use case (which works fine) would crash and burn. --Jacob
Re: svn commit: r1802336 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml
On 07/24/2017 12:39 PM, Yann Ylavic wrote: Hmm, don't we close the backend connection (i.e. conn->close = 1) whenever an error occurs in the fgci loop? What do you mean by "queue up for later", by whom? Where do that coonection go on the httpd side? I mean that the FCGI application (PHP-FPM) has a listen queue for connections. I haven't looked into the source to see how this queue is implemented. FPM has a status page that can be set up to debug these sorts of things, which I might try to enable later this week for more research. I think the "correct" way to go is to query the app for the max connection number, use that if the admin hasn't set up another max, and warn if the admin has forced us to use a max that's more than what the app can handle concurrently. --Jacob
Re: svn commit: r1802336 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml
On 07/24/2017 11:47 AM, Helmut K. C. Tessarek wrote: I can try to reproduce it when I have set up a VM to run tests. Unfortunately I currently do not have the time to do so. Maybe in a few days. Thanks! If this is the root cause of lost POSTs, then that'd be a good reason to implement FCGI_GET_VALUES support in mod_proxy_fcgi so we can query the maximum number of connections from the application itself. --Jacob
Re: svn commit: r1802336 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml
vOn 07/24/2017 11:34 AM, Helmut K. C. Tessarek wrote: On 2017-07-24 13:42, Jacob Champion wrote: Any chance this is because of the hang I mentioned? It could be, but this doesn't really change anything. We can't really help debug your problems very well if we can't reproduce them. Knowing whether this is the root cause or not is important, so we can decide what to do next. --Jacob
Re: svn commit: r1802336 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml
On 07/24/2017 10:40 AM, Helmut K. C. Tessarek wrote: In my case it screwed up the POST request by not doing what should have been done with the request. In the end the request was lost. (due to timeout, not processing it, or for whatever reason) Any chance this is because of the hang I mentioned? --Jacob
Re: svn commit: r1802336 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml
On 07/19/2017 04:56 AM, Yann Ylavic wrote: The comment in proxy_fcgi says: /* This scheme handler does not reuse connections by default, to * avoid tying up a fastcgi that isn't expecting to work on * parallel requests. But if the user went out of their way to * type the default value of disablereuse=off, we'll allow it. */ So could it be an fpm/application bug, maybe also suggested in the link provided by Luca where it's also said that the issue happens with other servers too (e.g. nginx)? I was able to reproduce a hang with PHP-FPM and enablereuse=on, but I don't think it's UDS-specific. (Haven't tried with TCP yet, though.) If the maximum number of connections opened by httpd to PHP-FPM exceeds the maximum number of requests that FPM is configured to handle in parallel, the extra connections will be queued up for later. But since we're no longer closing connections once a request finishes, those queued connections will hang until we hit the ProxyTimeout. It's important for admins to match the Proxy's max= parameter with their backend's configuration, which is something you didn't have to worry about as much with enablereuse=off. I have still not been able to reproduce the "messed up POSTs" that other people are reporting with UDS+enablereuse. --Jacob
Re: mod_proxy_fcgi and flush
On 07/18/2017 01:38 AM, Luca Toscano wrote: I didn't do it on purpose because I didn't want to mess with the main apr_poll, but if you find an elegant solution I am all for it. It'll take some work, but I think it's doable. My understanding is that in this case we don't need to listen to POLLOUT events since we are focusing on flushing (giving priority to it), and then we'll pay attention to POLLOUT when the main apr_poll will happen. There's nothing semantically wrong with doing that, but I think it can lead to some hard-to-debug performance issues in certain cases. Especially if outgoing chunks from the application are blocked waiting on incoming chunks for the client. There are some more issues that came up while I was playing around with the architecture: - Reads from the request body brigade are blocking, which leads to a common pattern: the backend has written data that is ready to be sent to the client, but it's not going anywhere because we are waiting for the client to send something. - If the backend sends FCGI_END_REQUEST without closing its stdout stream, we don't seem to correctly end the response with a zero-length chunk. I have not investigated this fully yet, but maybe it has something to do with not correctly sending an EOS bucket? - For scripts that are not running in NPH mode, we're required by the CGI spec to strip any incoming transfer-codings and present a final Content-Length to the application. Omitting CONTENT_LENGTH is supposed to mean that there is no request body. But for incoming chunked transfers, we just pass the chunks on to the backend without a CONTENT_LENGTH, which appears to confuse e.g. PHP-FPM. Jim pointed out that mod_proxy already has the concept of request body spooling, so we should probably make use of it. --Jacob
Re: mod_proxy_fcgi and flush
On 07/14/2017 02:29 AM, Luca Toscano wrote: http://home.apache.org/~elukey/httpd-2.4.x-mod_proxy_fcgi-force_flush-v3.patch created, I tested it quickly and it seems working fine (still unsure about using r->connection->pool vs conn->pool in palloc). More tests following in the weekend :) Some thoughts: - This will flush each time a POLLIN event is successfully handled, even if the event doesn't cause data to be put on the brigade (as is the case for STDERR or END_REQUEST records, or for the empty end-of-stream record). - While we're waiting for a POLLIN event in auto-flush mode, we're not listening to POLLOUT events. Seems like we could/should merge the apr_poll calls into one. I'm playing around with that now. --Jacob
Re: svn commit: r1801997 - /httpd/httpd/branches/2.4.x/STATUS
On 07/14/2017 03:32 PM, yla...@apache.org wrote: + *) mod_proxy_wstunnel: Fix detection of unresponded request which could have + led to spurious HTTP 502 error messages sent on upgrade connections. + PR 61283 + trunk patch: http://svn.apache.org/r1754164 + http://svn.apache.org/r1801994 + http://svn.apache.org/r1801995 + 2.4.x patch: http://home.apache.org/~ylavic/patches/httpd-2.4.x-mod_proxy_wstunnel-PR61283.patch + +1: ylavic + Thanks for this! I started putting together a backport proposal but got heavily sidetracked... --Jacob
Re: svn commit: r1801594 - in /httpd/httpd/trunk: docs/manual/mod/mod_proxy_wstunnel.xml modules/proxy/mod_proxy_wstunnel.c
On 07/11/2017 05:36 AM, Yann Ylavic wrote: I think it's quite hazardous to use/allow ANY and would prefer the upgrade_method (worker->s->upgrade) to be a list of acceptable protocols. I think both ANY *and* NONE are dangerous. Both of them turn proxy_wstunnel into a generic TCP forwarder (and NONE does so without any opt-in on the client's part). The admin surely knows which protocol(s) the backend supports, the issue being that otherwise most backends will ignore the Upgrade and hence the connection will continue in normal HTTP (tunneled w/o any protocol checking). +1. Even once we implement the protocol list, we should still double-check that the protocol is actually upgraded before we start forwarding back and forth. IMO the Upgrade handling should be part of mod_proxy_http (not _wstunnel) and depend on whether or not the backend accepted it. This I don't necessarily agree with as much... for now, Upgrade handling belongs where it's needed, and if there are duplicate pieces of code, we probably need to pull them into the core, not a different proxy module. It was already discussed in [1], well, I can't say that the idea was unanimous at that time... Yeah, I don't understand the turn that conversation took. We're talking about a feature that can be used for reverse-proxying, and there's nothing to CONNECT to. --Jacob
Re: svn commit: r1730079 - in /httpd/httpd/trunk: Makefile.in acinclude.m4 build/config_vars.sh.in
Some time this week, I'm going to propose this patch for backport, since
I rely on it for the `make check` feature and I want to get that into 2.4.x.
Rainer, if you (or anyone else) have reservations, please let me know.
--Jacob
On 02/12/2016 09:46 AM, rj...@apache.org wrote:
Author: rjung
Date: Fri Feb 12 17:46:38 2016
New Revision: 1730079
URL: http://svn.apache.org/viewvc?rev=1730079&view=rev
Log:
Use different variables to track normal
modules and MPMs during build.
Normal modules and MPMs follow different
rules in the config, e.g. we are only
allowed to have one active LoadModule
for an MPM in the config.
As a side effect, LoadModule for MPMs
will now come before LoadModule for
the normal modules.
Modified:
httpd/httpd/trunk/Makefile.in
httpd/httpd/trunk/acinclude.m4
httpd/httpd/trunk/build/config_vars.sh.in
Modified: httpd/httpd/trunk/Makefile.in
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/Makefile.in?rev=1730079&r1=1730078&r2=1730079&view=diff
==
--- httpd/httpd/trunk/Makefile.in (original)
+++ httpd/httpd/trunk/Makefile.in Fri Feb 12 17:46:38 2016
@@ -45,7 +45,7 @@ install-conf:
if [ -f $$i ] ; then \
( \
n_lm=`awk 'BEGIN {n=0} /@@LoadModule@@/ {n+=1} END {print
n}' < $$i`; \
- if test $$n_lm -eq 0 -o "x$(DSO_MODULES)" = "x"; then \
+ if test $$n_lm -eq 0 -o "x$(MPM_MODULE)$(DSO_MODULES)" =
"x"; then \
sed -e 's#@@ServerRoot@@#$(prefix)#g' \
-e 's#@@Port@@#$(PORT)#g' \
-e 's#@@SSLPort@@#$(SSLPORT)#g' \
@@ -68,29 +68,38 @@ install-conf:
else \
have_cgid="0"; \
fi; \
+ for j in $(MPM_MODULES) "^EOL^"; do \
+ if test $$j != "^EOL^"; then \
+ if echo ",$(ENABLED_MPM_MODULE),"|$(EGREP)
",$$j," > /dev/null ; then \
+ loading_disabled=""; \
+ else \
+ loading_disabled="#"; \
+ fi; \
+ echo "$${loading_disabled}LoadModule
$${j}_module $(rel_libexecdir)/mod_$${j}.so"; \
+ fi; \
+ done; \
for j in $(DSO_MODULES) "^EOL^"; do \
if test $$j != "^EOL^"; then \
if echo ",$(ENABLED_DSO_MODULES),"|$(EGREP)
",$$j," > /dev/null ; then \
loading_disabled=""; \
else \
loading_disabled="#"; \
- mpm=`echo $$j|sed
s/_.*//`; \
- if test "$(LOAD_ALL_MODULES)" = "yes" -a
"$$mpm" != "mpm"; then \
+ if test "$(LOAD_ALL_MODULES)" =
"yes"; then \
loading_disabled=""; \
fi; \
fi; \
- if test $$j = "cgid" -a
"$$have_cgi" = "1"; then \
- echo ""; \
- echo "
$${loading_disabled}LoadModule $${j}_module $(rel_libexecdir)/mod_$${j}.so"; \
- echo
""; \
- elif test $$j = "cgi" -a
"$$have_cgid" = "1"; then \
- echo ""; \
- echo "
$${loading_disabled}LoadModule $${j}_module $(rel_libexecdir)/mod_$${j}.so"; \
- echo
""; \
- else \
- echo
"$${loading_disabled}LoadModule $${j}_module $(rel_libexecdir)/mod_$${j}.so"; \
- fi; \
+ if test $$j = "cgid" -a "$$have_cgi" =
"1"; then \
+ echo ""; \
+
Re: mod_proxy_fcgi and flush
On Jul 8, 2017 6:14 PM, "Nick Kew" wrote: > > > It probably makes sense to work on a nonblocking architecture for > > > proxied responses in general. Is that really the issue in the first place? We have a concept of flushing, and can implement more finely-tuned throughput than merely blocking vs non-blocking. The point at issue is for PHP to communicate a flush with proxy_fcgi, and for proxy_fcgi then to honour it. It seems one or both of those things isn't happening. Not sure yet, but based on Luca's note, I think there's a good chance that my skim of the code gave me the wrong idea. If FPM sends a full message in a flush (and I can't see why it wouldn't) this might be fixable with a single FPM option. --Jacob
Re: [VOTE] Release Apache httpd 2.4.27 as GA
[x] +1: Good to go Ubuntu 16.04 x64, test suites for httpd and mod_websocket 0.1.1 with - APR 1.5.2, APR-Util 1.5.4 - OpenSSL 1.0.2g (Debian) - event, prefork, worker - no brotli, no mod_php --Jacob
Re: [VOTE] Release httpd-2.2.34
On 07/06/2017 12:33 PM, William A Rowe Jr wrote: [ ] Release 2.2.34 as legacy GA +1 Ubuntu 16.04, worker/prefork and mod_websocket 0.1.1. [ ] Retire the 2.2.x branch from any further maintenance. +1 --Jacob
Re: mod_proxy_fcgi and flush
On 07/06/2017 08:25 PM, Helmut K. C. Tessarek wrote: On 2017-07-06 14:54, Jacob Champion wrote: It probably makes sense to work on a nonblocking architecture for proxied responses in general. I'm not familiar with that particular code, but would be interested in looking into it. Does anybody volunteer as a mentor? I'm probably not the person you're looking for; I don't know the mod_proxy code very well. You may find that my root cause analysis is completely incorrect. But, if you'd like to bounce ideas off me, go for it. (As Luca already knows, I can be a little sporadic when it comes to this sort of thing. Fair warning! :) ) #httpd-dev on Freenode is also a place -- very quiet, usually, but I try to be there when I can. --Jacob
Re: mod_proxy_fcgi and flush
On 07/06/2017 11:13 AM, Jim Jagielski wrote: works 4 me... Doesn't for me. E.g. with a script like it takes 1 second to receive a single chunk with both lines in it. From a quick skim I assume this is because we don't use nonblocking sockets in the proxy implementation. (There's even a note in mod_proxy_fcgi that says, "Yes it sucks to [get the actual data] in a second recv call, this will eventually change when we move to real nonblocking recv calls.") On 07/06/2017 11:08 AM, Helmut K. C. Tessarek wrote: > What is your take on this? If I'm honest, my brutally blunt take on it is "stop using HTTP to try to emulate push notifications within a single response; pretty much everything in the ecosystem is actively working against you at this point; responses are designed to be cacheable and deliverable as a unit, not as multiple pieces; and we've had *real* solutions like WebSocket for five years now rabble rabble rabble." But I don't actually think that's going to be the accepted answer. It probably makes sense to work on a nonblocking architecture for proxied responses in general. -Jacob
Re: 2.4.27
On 07/06/2017 10:09 AM, Reindl Harald wrote: with removing mpm_prefork support for H2 you kill HTTP2 support for a lot of production setups which may consider switch to H2 in the future and for sure not rework there whole configuration but put a proxy like Trafficserver in front and forget about httpd at this point at all I think the fallout is more nuanced than that. The mod_http2 architecture currently cannot be mixed with prefork; it can lead to deadlock, and that's not okay for production systems in any way. Administrators using prefork who would like to switch to HTTP/2 in the future need to understand the limitations of the prefork architecture they have selected. And sure, our users can request that we implement a solution that "just works" with prefork, with the parent dispatcher that Stefan has mentioned, and we can weigh the cost/benefit of implementing it. But IMO it's not that onerous to ask our users to upgrade to a modern MPM if they want a nice new protocol. There are costs to making new things work with old machinery, and they affect you (the users) in real ways, even if you do not see them yourself. --Jacob
Re: 2.4.27 T&R ... holding off
On 07/06/2017 08:13 AM, Jim Jagielski wrote: Due to the questions around lua and apr_table and the change regarding http2 and prefork, doing a T&R of 2.4.27 right now does not seem prudent. I am holding off until we determine what to do about both "issues" IMO we are good to go with mod_lua. CHANGES has been updated to point out the compatibility break for clients. --Jacob
Re: svn commit: r1800835 - in /httpd/httpd/branches/2.4.x: ./ CHANGES modules/lua/README modules/lua/config.m4 modules/lua/lua_apr.c modules/lua/lua_config.c modules/lua/lua_request.c modules/lua/mod_
On 07/06/2017 07:21 AM, Jim Jagielski wrote: From IRC: [10:09:37] I've personally never used apr_table like described by jchampion_ [10:09:46] and I don't believe it's documented? [10:10:15] if you want to set a header, you'd use r.headers_out['foo'] = 'bar' [10:10:42] so tbh I'd be in favor of just scrapping that bit [10:10:54] and fixing the tests to not use it Cool. Let's revert the tests and add CHANGES. --Jacob
Re: svn commit: r1800835 - in /httpd/httpd/branches/2.4.x: ./ CHANGES modules/lua/README modules/lua/config.m4 modules/lua/lua_apr.c modules/lua/lua_config.c modules/lua/lua_request.c modules/lua/mod_
On 07/05/2017 12:30 PM, Jacob Champion wrote: So... do we care? If we do, here's a potential patch to *partially* return to the previous behavior: --- modules/lua/lua_apr.c +++ modules/lua/lua_apr.c @@ -97,6 +97,12 @@ int ap_lua_init(lua_State *L, apr_pool_t *p) lua_gettable(L, 2); lua_settable(L, 1); +#if LUA_VERSION_NUM >= 502 +/* For compatibility, maintain the "apr_table" global that was used by the + * old luaL_register() implementation. */ +lua_setglobal(L, "apr_table"); +#endif + return 0; } Lua's package.loaded["apr_table"] is still not set here, like it was with luaL_register. From quick Googling, I think that means it won't work with the deprecated module() system. I'm not a Lua programmer, so comments/review/advice welcome. --Jacob
Re: svn commit: r1800835 - in /httpd/httpd/branches/2.4.x: ./ CHANGES modules/lua/README modules/lua/config.m4 modules/lua/lua_apr.c modules/lua/lua_config.c modules/lua/lua_request.c modules/lua/mod_
On 07/05/2017 11:19 AM, Jacob Champion wrote: So the effective change is that "apr_table" is no longer a global name, is that correct? Unfortunately, from poking around on GitHub, it looks like removing this global variable might break at least one production script [1]. Not because they're using the function table, but because they key on its existence to know they're talking to httpd. In addition, here's code that used to work but no longer does: apr_table.set(r.headers_out, "X-Header", "value") So... do we care? What are the compatibility guarantees we make for mod_lua, since it's experimental? --Jacob [1] https://github.com/sailorproject/sailor/blob/master/src/sailor.lua#L31
Re: svn commit: r1800835 - in /httpd/httpd/branches/2.4.x: ./ CHANGES modules/lua/README modules/lua/config.m4 modules/lua/lua_apr.c modules/lua/lua_config.c modules/lua/lua_request.c modules/lua/mod_
On 07/04/2017 03:28 PM, rj...@apache.org wrote:
The following lua 5.2 and 5.3 compat change
should be checked for runtime correctness
by someone more knowledgeable about lua.
Index: modules/lua/lua_apr.c
--- modules/lua/lua_apr.c (original)
+++ modules/lua/lua_apr.c Tue Jul 4 20:48:43 2017
@@ -82,7 +82,11 @@ static const luaL_Reg lua_table_methods[
int ap_lua_init(lua_State *L, apr_pool_t *p)
{
luaL_newmetatable(L, "Apr.Table");
+#if LUA_VERSION_NUM < 502
luaL_register(L, "apr_table", lua_table_methods);
+#else
+luaL_newlib(L, lua_table_methods);
+#endif
So the effective change is that "apr_table" is no longer a global name,
is that correct? Looks like you brought this up in [1] but there was
never a final decision.
Everything else in the patch looks good to me, and passes the test suite
on Ubuntu 16.04 with Lua 5.1/2/3.
--Jacob
[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=56753#c10
Re: perl test framework
On 07/05/2017 04:01 AM, Jim Jagielski wrote: I am curious... what versions of Perl are people using when running the Perl test framework? It seems that, at least to me, it is quite picky regarding versions, at least on macOS. 5.22.1, as distributed with Ubuntu 16.04 (plenty of Debian patches). --Jacob
Re: 2.4.27
On 07/03/2017 04:45 AM, Eric Covener wrote: +1 +1 --Jacob
Re: FastCGI env-vars
On 07/02/2017 08:44 AM, William A Rowe Jr wrote: I'm reading https://tools.ietf.org/html/rfc3875#section-4.1.5 as the PATH_INFO is entirely distinct from QUERY_STRING. Right. SCRIPT_NAME, PATH_INFO, and QUERY_STRING are intended to be three distinct parts of the Script-URI (see Section 3.3). I.e. you should be able to percent-encode and concatenate them (with the correct delimiters) to get an equivalent URI. --Jacob
Re: svn commit: r1800306 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_actions.c modules/proxy/mod_proxy_fcgi.c
On 06/30/2017 11:40 AM, Jacob Champion wrote: As far as I can tell it has no downsides, so my only request is that we add it to CHANGES (or some documentation, somewhere) and get a test in place before it goes back in. I may be able to get to that later this afternoon. This is taking me longer than I wanted, so in the interest of time, I've just gone ahead and added the un-revert to the backport proposal. I hope to get to the tests for it next week. Regression tests still pass for me; vote away! --Jacob
Re: FastCGI env-vars
On 06/30/2017 09:43 AM, Jim Jagielski wrote: In any case, I think HEAD of the perl test framework is finally in shape to test and catch expectations regarding how we handle FCGI env-vars, both in "generic" situations as well as how php-fpm sees/expects them. At least, the current rev "passes" all tests based on my assumptions on what those expected values should be (based on my reading of the RFCs and the examples given in the various PRs)... Thanks for all your work on the framework! The new FPM tests look good to me, and they pass with both 2.4.20 and trunk, which is a good sign. --Jacob
Re: svn commit: r1800306 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_actions.c modules/proxy/mod_proxy_fcgi.c
On 06/30/2017 08:41 AM, Jacob Champion wrote: On 06/30/2017 08:37 AM, Jim Jagielski wrote: Well, in 2.4.26 is WAS/IS an entry in notes available to modules Well... hm. I guess that's a valid point. My preference is still to remove it since it's undocumented, but if anyone else would like to see it back in, I'm fine with that. After mulling it over a bit... I think you've convinced me, Jim. I would probably die of shame if someone started using that note in 2.4.26 and my "final patch" just extended the regression train. ;P As far as I can tell it has no downsides, so my only request is that we add it to CHANGES (or some documentation, somewhere) and get a test in place before it goes back in. I may be able to get to that later this afternoon. --Jacob
Re: svn commit: r1800306 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_actions.c modules/proxy/mod_proxy_fcgi.c
On 06/30/2017 08:37 AM, Jim Jagielski wrote: Well, in 2.4.26 is WAS/IS an entry in notes available to modules Well... hm. I guess that's a valid point. My preference is still to remove it since it's undocumented, but if anyone else would like to see it back in, I'm fine with that. Other opinions? --Jacob
Re: svn commit: r1800307 - /httpd/httpd/branches/2.4.x/STATUS
On 06/30/2017 08:10 AM, William A Rowe Jr wrote: -1 on showstopper. It's a bug, no security implications, cope with it. Thousands of bugs pass through STATUS, what makes yours special? It's a reinstatement of my previous 2.4.26 showstopper, which got no objections, was unaddressed by the proposed patch for it, and is finally addressed with this patch. We've busted people three releases in a row, and we already have emails on the list asking if we're going to fix it next release, or if those affected need to hardwire workarounds into their stacks, which is exactly what we don't want. My showstopper stands unless more PMC members object, in which case I will retract it. --Jacob
Re: svn commit: r1800306 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_actions.c modules/proxy/mod_proxy_fcgi.c
On 06/30/2017 05:32 AM, Jim Jagielski wrote: I still think that the below has value and should not be/have-been reverted. I'm not arguing that it doesn't have value in theory, but IMO it doesn't belong in 2.4.x without a client. Right now it's just dead code. Anyone opposed to me re-adding it to trunk and removing it from the backport proposal? Yes. Unless you have a use case for it at this moment, I'd prefer that it be re-backported if and when that use case materializes, but I will defer to the majority here. --Jacob
Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS
On 06/27/2017 04:59 PM, Eric Covener wrote: I would just as well pull this block out entirely rather than taking the "fpm||" half of the test out. It seems like if you go out of your way to run a script with PATH_INFO set as some parameter that we shouldn't negate that. And like the non path_info case, nobody has ever asked us for this. Checked in as r1800306 and proposed for backport. --Jacob
Re: svn commit: r1800181 - /httpd/httpd/branches/2.4.x/STATUS
On 06/28/2017 11:18 AM, Yann Ylavic wrote: On Wed, Jun 28, 2017 at 7:28 PM, William A Rowe Jr wrote: Can we get one more pair of eyeballs (or cross-vote the other branch) so this is properly accepted? Confirmed on my side for the 2.2.x branch. And mine, for 2.4.x. --Jacob
Re: [VOTE] Release httpd-2.2.33
On 06/27/2017 10:21 AM, William A Rowe Jr wrote: If voters would rather that I address https://bz.apache.org/bugzilla/show_bug.cgi?id=61220 and reroll, I'm fine with that. I think that would be good, since we're planning to make this the Final Release. --Jacob
Re: svn commit: r1800050 - in /httpd/test/framework/trunk: scripts/uds-test.pl t/modules/proxy.t
On 06/27/2017 04:39 AM, j...@apache.org wrote:
Author: jim
Date: Tue Jun 27 11:39:02 2017
New Revision: 1800050
URL: http://svn.apache.org/viewvc?rev=1800050&view=rev
Log:
Make this self-contained... Should really pull do_do_run_run
out :)
Removed:
httpd/test/framework/trunk/scripts/uds-test.pl
Modified:
httpd/test/framework/trunk/t/modules/proxy.t
Modified: httpd/test/framework/trunk/t/modules/proxy.t
URL:
http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/modules/proxy.t?rev=1800050&r1=1800049&r2=1800050&view=diff
==
--- httpd/test/framework/trunk/t/modules/proxy.t (original)
+++ httpd/test/framework/trunk/t/modules/proxy.t Tue Jun 27 11:39:02 2017
@@ -5,6 +5,7 @@ use Apache::Test;
use Apache::TestRequest;
use Apache::TestUtil;
use Apache::TestConfig ();
+require IO::Select;
my $num_tests = 20;
if (have_min_apache_version('2.4.7')) {
@@ -105,14 +106,56 @@ if (have_module('alias')) {
skip "skipping tests without mod_alias" foreach (1..4);
}
-if (have_min_apache_version('2.4.7')) {
-my $pid = fork;
-if ($pid) {
-system './scripts/uds-test.pl';
+sub uds_script
+{
+use Socket;
+use strict;
+
+my $socket_path = '/tmp/test-ptf.sock';
+unlink($socket_path);
+my $sock_addr = sockaddr_un($socket_path);
+socket(my $server, PF_UNIX, SOCK_STREAM, 0) || die "socket: $!";
+bind($server, $sock_addr) || die "bind: $!";
+listen($server,1024) || die "listen: $!";
+if (accept(my $new_sock, $server)) {
+my $data = <$new_sock>;
+print $new_sock "HTTP/1.0 200 OK\r\n";
+print $new_sock "Content-Type: text/html\r\n\r\n";
+print $new_sock "Hello
World$data\n";
+close $new_sock;
+}
+unlink($socket_path);
+}
+
+sub do_do_run_run ($$)
+{
+my $msg = shift;
+my $func = shift;
+
+pipe(READ_END, WRITE_END);
+my $pid = fork();
+unless (defined $pid) {
+t_debug "couldn't fork $msg";
+ok 0;
+exit;
+}
+if ($pid == 0) {
+print WRITE_END 'x';
+close WRITE_END;
+$func->();
exit;
}
# give time for the system call to take effect
-sleep 2;
+unless (IO::Select->new((\*READ_END,))->can_read(2)) {
+t_debug "timed out waiting for $msg";
+ok 0;
+kill 'TERM', $pid;
+exit;
+}
+}
Same problem here -- the signal back to the parent has to come after we
call listen() in the child.
--Jacob
Re: svn commit: r1800066 - in /httpd/test/framework/trunk: Misc.pm t/modules/proxy_fcgi.t
On 06/27/2017 07:28 AM, j...@apache.org wrote:
Author: jim
Date: Tue Jun 27 14:28:50 2017
New Revision: 1800066
URL: http://svn.apache.org/viewvc?rev=1800066&view=rev
Log:
Re-use the runner sub function...
Modified:
httpd/test/framework/trunk/Misc.pm
httpd/test/framework/trunk/t/modules/proxy_fcgi.t
Modified: httpd/test/framework/trunk/Misc.pm
URL:
http://svn.apache.org/viewvc/httpd/test/framework/trunk/Misc.pm?rev=1800066&r1=1800065&r2=1800066&view=diff
==
--- httpd/test/framework/trunk/Misc.pm (original)
+++ httpd/test/framework/trunk/Misc.pm Tue Jun 27 14:28:50 2017
@@ -28,7 +28,7 @@ BEGIN {
# Just a bunch of useful subs
}
-sub do_do_run_run ($$)
+sub do_do_run_run
{
my $msg = shift;
my $func = shift;
@@ -43,7 +43,7 @@ sub do_do_run_run ($$)
if ($pid == 0) {
print WRITE_END 'x';
close WRITE_END;
-$func->();
+$func->(@_);
exit;
}
# give time for the system call to take effect
@@ -53,6 +53,7 @@ sub do_do_run_run ($$)
kill 'TERM', $pid;
exit;
}
+return $pid;
}
Modified: httpd/test/framework/trunk/t/modules/proxy_fcgi.t
URL:
http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/modules/proxy_fcgi.t?rev=1800066&r1=1800065&r2=1800066&view=diff
==
--- httpd/test/framework/trunk/t/modules/proxy_fcgi.t (original)
+++ httpd/test/framework/trunk/t/modules/proxy_fcgi.t Tue Jun 27 14:28:50 2017
@@ -5,6 +5,8 @@ use Apache::Test;
use Apache::TestRequest;
use Apache::TestUtil;
+use Misc;
+
my $have_fcgisetenvif= have_min_apache_version('2.4.26');
my $have_fcgibackendtype = have_min_apache_version('2.4.26');
@@ -24,60 +26,32 @@ Apache::TestRequest::module("proxy_fcgi"
# Launches a short-lived FCGI daemon that will handle exactly one request with
# the given handler function. Returns the child PID; exits on failure.
-sub run_fcgi_handler($$)
+
+sub fcgi_request
{
my $fcgi_port= shift;
my $handler_func = shift;
-# Use a pipe for ready-signalling between the child and parent. Much faster
-# (and more reliable) than just sleeping for a few seconds.
-pipe(READ_END, WRITE_END);
-my $pid = fork();
-
-unless (defined $pid) {
-t_debug "couldn't fork FCGI process";
-ok 0;
-exit;
-}
+# Child process. Open up a listening socket.
+my $sock = FCGI::OpenSocket(":$fcgi_port", 10);
-if ($pid == 0) {
-# Child process. Open up a listening socket.
-my $sock = FCGI::OpenSocket(":$fcgi_port", 10);
-
-# Signal the parent process that we're ready.
-print WRITE_END 'x';
-close WRITE_END;
This isn't an equivalent transformation. It's important that the socket
is opened *before* signaling the parent; otherwise there's a race and
the parent might try to ping the child before it's ready.
--Jacob
Re: svn commit: r1799375 - /httpd/httpd/trunk/server/util.c
On 06/20/2017 11:08 PM, William A Rowe Jr wrote: Sorry but I reraise my objection and veto worthless cpu cycles. Hi Bill, For posterity, can I get a succinct description of your technical justification for this veto? --Jacob
Re: svn commit: r1799689 - in /httpd/test/framework/trunk/t: conf/proxy.conf.in htdocs/modules/proxy/fcgi/ htdocs/modules/proxy/fcgi/index.php modules/proxy_fcgi.t
On 06/23/2017 01:22 PM, Jim Jagielski wrote: This is cool. Thx. It's inline with what I was hoping to do. No problem! I'm curious though Since we never actually *run* php-fpm on the PHP script, we never see what PHP actually determines are these parameters, right? So like you said on IRC: the entire point of PHP-FPM mode is to work with PHP as it exists today. But "work" means different things to different people. Some people just want the scripts to *run*; other people need the values of the envvars to remain exactly compatible because they use them within their scripts. So the regression test for a default, unset BackendType doesn't really need to run FPM, because we can't change the envvar values we send by default anyway. (Because that would potentially break, and has already broken, users who are using those values for some other reason.) What we need to check instead is that the unset BackendType behaves exactly as 2.4.20 did, so that no users upgrading from pre-2.4.20 are broken by our latest release. I don't see a need for an FPM mode at moment, because the 2.4.20 behavior that should become the default in 2.4.27 *seemed* to work for the vast majority of people. (I was the person who filed the proxy: prefix bug, and I have a better solution to that now with Eric's ProxyFCGISetEnvIf.) But we shipped FPM mode and I can't very well remove it. If you want FPM mode to do something differently from 2.4.20's behavior, it'd be good to explain what that is and why you want it. (All that said, an integration test with FPM would be great to have on top of the regression test for obvious reasons. It just serves a different purpose.) --Jacob
Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS
On 06/23/2017 09:42 AM, Jim Jagielski wrote: Over this weekend I may try to extend the current fcgi testing to include php-fpm... we should not, imo, fold in any patches until we can test each applicable use case and avoid regressions. I've also added one of the known 2.4.26 regressions to the existing tests. I'll be going through today and adding cases for the GENERIC backend as well. --Jacob
Re: svn commit: r1799455 - /httpd/httpd/trunk/docs/manual/mod/
On 06/21/2017 07:33 AM, j...@apache.org wrote: Modified: httpd/httpd/trunk/docs/manual/mod/allmodules.xml URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/allmodules.xml?rev=1799455&r1=1799454&r2=1799455&view=diff == --- httpd/httpd/trunk/docs/manual/mod/allmodules.xml (original) +++ httpd/httpd/trunk/docs/manual/mod/allmodules.xml Wed Jun 21 14:33:29 2017 @@ -135,6 +135,7 @@ event.xml mpm_netware.xml mpmt_os2.xml + overrides.xml prefork.xml mpm_winnt.xml worker.xml Hey Jim, you may need to SVN-update your docs-build directory. See [1]. --Jacob [1] https://lists.apache.org/thread.html/1b21861f6e090c564a537f68450d38c80ba49def5b0b7d89dbad1306@%3Cdev.httpd.apache.org%3E
Re: buildbot failure in on httpd-trunk
On 06/22/2017 02:00 AM, Stefan Eissing wrote: However, running 'make depend' on my dev checkout with a custm --prefix and libs in that prefix location gives errors such as /Users/sei/projects/httpd/trunk/modules/filters/mod_xml2enc.c:27:10: fatal error: 'libxml/encoding.h' file not found #include So, just adding depend to the dependencies will not work for all of us. Hmm. If I get some spare cycles, I can see if I can switch us to a more precise dependency generation system. For now, the nightly-clean autobuilds will catch issues like this. I'm not sure I want to add `make depend` to the buildbot yet without testing its failure modes, and for now the autobuild behavior is good enough, if imperfect. --Jacob
Re: [users@httpd] if directive not being respected in Apache 2.4.6
On 06/21/2017 09:02 AM, William A Rowe Jr wrote: ++1 EXEC_ON_READ is meaningful to we devs, but not for a general audience. 'Immediate Global' or something similar? What other 2 or 3 word caption works to describe this well for end users researching Define, or LoadModule, etc? "Preprocessor Directive"? "Load-Time Directive"? I'll give it some thought. --Jacob
Re: buildbot failure in on httpd-trunk
On 06/21/2017 11:58 AM, Jacob Champion wrote: On 06/21/2017 11:31 AM, Yann Ylavic wrote: The "make depend" (after initial ./configure) is missing? Is dependency generation not part of the default make invocation? ...from testing, it looks like it is not. Seems like we should change that, since (I assume) it just bit Jim. And now that I think about it, I'm almost certain it's bitten me before. I generally expect a 'make' invocation to Do the Right Thing (tm), from scratch. --Jacob
Re: buildbot failure in on httpd-trunk
On 06/21/2017 11:31 AM, Yann Ylavic wrote: The "make depend" (after initial ./configure) is missing? Is dependency generation not part of the default make invocation? --Jacob
Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS
On 06/20/2017 02:19 PM, Jacob Champion wrote: Here's why I'm asking: if I were to propose the attached patch for backport, what is the test case that *should* fail but doesn't? (proxy_fcgi.t passes, no problem.) And once we get that test case, can we show that it actually addresses a valid PHP-FPM use case, or is it a feature without a user? Any thoughts on this? --Jacob
Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS
On 06/20/2017 06:39 PM, Jan Ehrhardt wrote: BTW: the developers at Directadmin are aware of this bug. https://forum.directadmin.com/showthread.php?t=54952&page=2&p=281618#post281618 I ran into it while updating my Centos 6 servers. Thanks for the heads up. CC's are coming in on the related bugs in Bugzilla as well. Anyone opposed to a users@ announcement on the issue? --Jacob
Re: svn commit: r1799375 - /httpd/httpd/trunk/server/util.c
Reverted while the veto is in effect. On 06/20/2017 11:08 PM, William A Rowe Jr wrote: Sorry but I reraise my objection and veto worthless cpu cycles. Yep, but it's public now, which was my goal. Background for the uninitiated: CVE-2017-7668 is a buffer overrun caused by Bill's patch in the Strict-HTTP backport, which inverted test_char_table's classification of the NULL character from "is an HTTP token stop" to "is NOT an HTTP token stop". A loop that relied on the previous behavior to stop at the end of strings was broken, causing a vulnerability. My patch introduces redundant checks to ensure that even if NULL's classification changes in the future, all loops using test_char_table are provably correct without code changes, since we've already screwed this up once. (Please understand that my goal here is not to point fingers at you, Bill, for the bug. I'm very thankful that you spent as much time as you did on the HTTP-strict backport. My goal is to scrutinize how we follow up on our mistakes after they're made, to try to make sure they don't happen again, and to figure out why a logically correct patch is being *vetoed* by you.) The correct fix to your concern is to document all expected behavior of the null but in gen_test_char.c - and in such tests a /* !c && */ notation is fine. That's a personal judgment call, and it deserves the opinion of others on the list. You've used a veto to ensure that my preferred solution can't even reach trunk and get votes for backport. That is my major concern here. If my patch goes to trunk and gets votes despite your concerns, it seems like that should be good enough. If it can't, and your preferred patch does get votes, great! At least it was all done fairly. Due to the way we assemble the code, I'm not convinced it that any compiler can optimize away these infrequent cases. I was under the impression that it was on you, as the one exercising the veto, to prove your case technically. But that's really neither here nor there, because in the end, I'm comfortable trading a handful of nanoseconds for provable correctness and improved auditability. And I think others should be able to express their opinion on the matter *without* the shadow of a veto over the alternative that you dislike. Why would anyone else here spend time arguing for a patch that's already procedurally DOA? But there were only two questionable values for \0, and in this case the answer is obvious. Invert the rule to a TOKEN char from the rather dubious TOKEN_STOP definition. Solved. Patches welcome. --Jacob
Re: buildbot failure in on httpd-trunk
On 06/21/2017 09:12 AM, William A Rowe Jr wrote: If two commits occur in a short enough period of time, the datestamp of the newly refreshed source may be earlier than the .o generated by the first update. The build system won't SVN-update in the middle of a build, and I assume the build bots are not set up to use-commit-times (?!) since that would break a bunch of stuff. I think this is just an old-fashioned Makefile dependency bug. --Jacob
Re: buildbot failure in on httpd-trunk
On 06/21/2017 09:06 AM, Jacob Champion wrote: Now to figure out why it took until the clean rebuild to catch, instead of the immediate build after the commit. Oh, there's probably no Makefile dependency on the header, right? Hmm. --Jacob
Re: buildbot failure in on httpd-trunk
On 06/21/2017 09:00 AM, build...@apache.org wrote: The Buildbot has detected a new failure on builder httpd-trunk while building . Full details are available at: https://ci.apache.org/builders/httpd-trunk/builds/682 It works! \o/ Now to figure out why it took until the clean rebuild to catch, instead of the immediate build after the commit. --Jacob
Re: svn commit: r1799356 - in /httpd/httpd/branches/2.2.x: ./ server/scoreboard.c
On 06/21/2017 01:38 AM, Yann Ylavic wrote: On Wed, Jun 21, 2017 at 10:19 AM, Joe Orton wrote: I believe many people find the "if constant CMP variable" style irritating. My internal parser has to reset after reading that because I assume the LHS is variable on first parse, so I have to mentally flip the logic to understand it. I don't know why really, it's stupid. The double layer of redundant parentheses are also annoying and force me to re-parse the statement to try to work out why they might be needed. +1, same brain issues here :) Fair enough. :D --Jacob
Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS
On 06/20/2017 01:35 PM, Jacob Champion wrote:
What requests and server config did you use with this test setup?
Here's why I'm asking: if I were to propose the attached patch for
backport, what is the test case that *should* fail but doesn't?
(proxy_fcgi.t passes, no problem.) And once we get that test case, can
we show that it actually addresses a valid PHP-FPM use case, or is it a
feature without a user?
--Jacob
diff --git modules/mappers/mod_actions.c modules/mappers/mod_actions.c
index ac9c3b7..2a67a27 100644
--- modules/mappers/mod_actions.c
+++ modules/mappers/mod_actions.c
@@ -186,8 +186,7 @@ static int action_handler(request_rec *r)
ap_field_noparam(r->pool, r->content_type);
if (action && (t = apr_table_get(conf->action_types, action))) {
-int virtual = (*t++ == '0' ? 0 : 1);
-if (!virtual && r->finfo.filetype == APR_NOFILE) {
+if (*t++ == '0' && r->finfo.filetype == APR_NOFILE) {
ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, APLOGNO(00652)
"File does not exist: %s", r->filename);
return HTTP_NOT_FOUND;
@@ -198,9 +197,6 @@ static int action_handler(request_rec *r)
* (will be REDIRECT_HANDLER there)
*/
apr_table_setn(r->subprocess_env, "HANDLER", action);
-if (virtual) {
-apr_table_setn(r->notes, "virtual_script", "1");
-}
}
if (script == NULL)
diff --git modules/proxy/mod_proxy_fcgi.c modules/proxy/mod_proxy_fcgi.c
index a268556..41292e8 100644
--- modules/proxy/mod_proxy_fcgi.c
+++ modules/proxy/mod_proxy_fcgi.c
@@ -321,7 +321,6 @@ static apr_status_t send_environment(proxy_conn_rec *conn, request_rec *r,
apr_status_t rv;
apr_size_t avail_len, len, required_len;
int next_elem, starting_elem;
-int fpm = 0;
fcgi_req_config_t *rconf = ap_get_module_config(r->request_config, &proxy_fcgi_module);
fcgi_dirconf_t *dconf = ap_get_module_config(r->per_dir_config, &proxy_fcgi_module);
@@ -354,8 +353,6 @@ static apr_status_t send_environment(proxy_conn_rec *conn, request_rec *r,
*qs = '\0';
}
}
-} else {
-fpm = 1;
}
if (newfname) {
@@ -364,38 +361,9 @@ static apr_status_t send_environment(proxy_conn_rec *conn, request_rec *r,
}
}
-#if 0
-ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(0)
- "r->filename: %s", (r->filename ? r->filename : "nil"));
-ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(0)
- "r->uri: %s", (r->uri ? r->uri : "nil"));
-ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(0)
- "r->path_info: %s", (r->path_info ? r->path_info : "nil"));
-#endif
-
ap_add_common_vars(r);
ap_add_cgi_vars(r);
-if (fpm || apr_table_get(r->notes, "virtual_script")) {
-/*
- * Adjust SCRIPT_NAME, PATH_INFO and PATH_TRANSLATED for PHP-FPM
- * TODO: Right now, PATH_INFO and PATH_TRANSLATED look OK...
- */
-const char *pend;
-const char *script_name = apr_table_get(r->subprocess_env, "SCRIPT_NAME");
-pend = script_name + strlen(script_name);
-if (r->path_info && *r->path_info) {
-pend = script_name + ap_find_path_info(script_name, r->path_info) - 1;
-}
-while (pend != script_name && *pend != '/') {
-pend--;
-}
-apr_table_setn(r->subprocess_env, "SCRIPT_NAME", pend);
-ap_log_rerror(APLOG_MARK, APLOG_TRACE4, 0, r,
- "fpm:virtual_script: Modified SCRIPT_NAME to: %s",
- pend);
-}
-
/* XXX are there any FastCGI specific env vars we need to send? */
/* Give admins final option to fine-tune env vars */
Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS
On 06/20/2017 12:23 PM, Jim Jagielski wrote: % cat fcgi.pl #!/usr/bin/env perl What requests and server config did you use with this test setup? --Jacob
Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS
On 06/20/2017 11:48 AM, Jim Jagielski wrote: Ahh... the tests from the orig bug report There have been several reports. I'm hoping to get the test case you were using to test the new `if (fpm ...` logic in mod_proxy_fcgi. Even if it was just a manual test; I just want to get it recorded in the suite. --Jacob
Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS
On 06/20/2017 10:55 AM, Jim Jagielski wrote: It's already in the wild. We do not guarantee bug compatibility. That's our judgment call based on adoption, expected user disruption, time in the wild, etc. The purpose of my Showstopper was to revert to known-good behavior. That didn't happen, not least because I didn't catch this bug in the backport, I wanted to keep things moving, and I +1'd it despite the presence of the rider patch that I tried unsuccessfully to keep out [1]. So that's on me (and that's why I'm grinding this particular axe). I want to fix the mistake I started last year, and not punish our users with yet another unusable default for the third release in a row. --Jacob [1] https://lists.apache.org/thread.html/539645ba41021f85a87ad397861cb8d09fb057f7fb7e9ed768781e85@%3Cdev.httpd.apache.org%3E
Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS
On 06/20/2017 10:55 AM, Jim Jagielski wrote: Last I checked, it's in the test framework... Quick grep for "SCRIPT_NAME" in the tests doesn't turn up anything; can you point me to it? --Jacob
Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS
On 06/20/2017 09:47 AM, Jacob Champion wrote: I think. Still trying to context switch back three months. Jim, do you have a good test case for the current FPM logic so we don't break that with a fix? --Jacob
Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS
On 06/20/2017 10:12 AM, Jim Jagielski wrote: All this is, IMO, moot until we have a *patch*. Agreed. See my other fork of this thread for my questions on that. Right now there is a work-around, which, again IMO, reduces the "need" to release something "now"... the only question is whether the patch changes the behavior of the 2 current settings or whether it adds a 3rd option (the latter is my recommendation). The faster we can patch, the less there is a need to introduce yet another "ProxyFcgiBackendType FPM-But-Better-And-Without-Bugs-This-Time" option. --Jacob
Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS
On 06/20/2017 10:00 AM, William A Rowe Jr wrote: You must presume it is in the wild, and shortening the exposure by a matter of days isn't significant. My point is that we should fix it ASAP. Days vs. more days may not be significant, but days vs. months is definitely significant when it comes to bug-compatibility and user expectations. --Jacob
Re: svn commit: r1799356 - in /httpd/httpd/branches/2.2.x: ./ server/scoreboard.c
On 06/20/2017 09:47 AM, wr...@apache.org wrote: Log: Make the range test legible Hmm, out of curiosity, is the legibility you mention from the parenthesization change or the switch to greater-than-or-equal for one side? I kind of like reading code that has all less-than comparisons, instead of mixed less-than and greater-than, because it means the logic is closer to the mathematics and the number line. For example, 0 < x < 5 becomes ((0 < x) && (x < 5)) y < 1 or 5 < y becomes ((y < 1) || (5 < y)) This is not a big deal; I just feel like typing about something trivial this morning. I realize the point of this patch is to fix the off-by-one. --Jacob
Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS
On 06/20/2017 09:07 AM, Jacob Champion wrote: Can we do a quick fixup and reroll before it's too late? And... what *is* the fixup? It looks like the logic here -- where we start at the end of SCRIPT_NAME (or the beginning of PATH_INFO) and work backwards -- is designed to stop at the first directory separator no matter what, which I completely missed in my review. It needs to stop wherever the "URL" part of the path ends and the "filesystem" part of the path begins. I think. Still trying to context switch back three months. --Jacob
Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS
On 06/20/2017 09:16 AM, William A Rowe Jr wrote: It's released into the wild, what is done is done. Of course. But having it in the wild for three days is different than having it in the wild for six months. --Jacob
Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS
On 06/20/2017 09:14 AM, William A Rowe Jr wrote: Would encourage us to wait at least a couple more days for other, unrelated regression reports to filter in while fixing this defect. But there is nothing stopping a 2.4.27 in rapid succession, we simply don't retroactively "retract" releases. Right, re-issuing 2.4.26 isn't what I meant. I just want to patch this up as quickly as possible so people don't standardize on the new behavior. --Jaccob
Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS
On 02/08/2017 07:56 PM, Eric Covener wrote: Assuming there's some alternate path that actually does change SCRIPT_NAME by default, we a) don't have any complaint about SCRIPT_NAME and b) have the SetEnv thing. If we want more options, maybe we can stash this older SCRIPT_NAME into a new variable and show how to copy it over SCRIPT_NAME? ...and restarting this conversation, since the new behavior seems to have a bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=61202 Can we do a quick fixup and reroll before it's too late? --Jacob
Re: CVE-2017-3167: ap_get_basic_auth_pw authentication bypass
On 06/19/2017 03:44 PM, William A Rowe Jr wrote: None at all, I have moderation and will push it on. They are on their way over to you. Thanks for the suggestion. --Jacob
Re: CVE-2017-3167: ap_get_basic_auth_pw authentication bypass
On 06/19/2017 03:35 PM, William A Rowe Jr wrote: Not to announce@httpd? users@ and dev@ aren't particularly broadcast channels. announce@a.o might be too wide an audience, but that's why we document the CVE's with short notes in the foundation-wide release announcement. At least, used to document them. I was following Jim's lead on the first CVE announcement. I'm not opposed to a [SECURITY] announcement for all five; just timid. :) Any opposed to me copying all five to announce@httpd? --Jacob
CVE-2017-3169: mod_ssl null pointer dereference
CVE-2017-3169: mod_ssl null pointer dereference Severity: Important Vendor: The Apache Software Foundation Versions Affected: httpd 2.2.0 to 2.2.32 httpd 2.4.0 to 2.4.25 Description: mod_ssl may dereference a NULL pointer when third-party modules call ap_hook_process_connection() during an HTTP request to an HTTPS port. Mitigation: 2.2.x users should either apply the patch available at https://www.apache.org/dist/httpd/patches/apply_to_2.2.32/CVE-2017-3169.patch or upgrade in the future to 2.2.33, which is currently unreleased. 2.4.x users should upgrade to 2.4.26. Credit: The Apache HTTP Server security team would like to thank Vasileios Panopoulos and AdNovum Informatik AG for reporting this issue. References: https://httpd.apache.org/security_report.html
CVE-2017-7668: ap_find_token buffer overread
CVE-2017-7668: ap_find_token buffer overread Severity: Important Vendor: The Apache Software Foundation Versions Affected: httpd 2.2.32 httpd 2.4.24 (unreleased) httpd 2.4.25 Description: The HTTP strict parsing changes added in 2.2.32 and 2.4.24 introduced a bug in token list parsing, which allows ap_find_token() to search past the end of its input string. By maliciously crafting a sequence of request headers, an attacker may be able to cause a segmentation fault, or to force ap_find_token() to return an incorrect value. Mitigation: 2.2.32 users should either apply the patch available at https://www.apache.org/dist/httpd/patches/apply_to_2.2.32/CVE-2017-7668.patch or upgrade in the future to 2.2.33, which is currently unreleased. 2.4.25 users should upgrade to 2.4.26. Credit: The Apache HTTP Server security team would like to thank Javier Jiménez (javij...@gmail.com) for reporting this issue. References: https://httpd.apache.org/security_report.html
CVE-2017-7679: mod_mime buffer overread
CVE-2017-7679: mod_mime buffer overread Severity: Important Vendor: The Apache Software Foundation Versions Affected: httpd 2.2.0 to 2.2.32 httpd 2.4.0 to 2.4.25 Description: mod_mime can read one byte past the end of a buffer when sending a malicious Content-Type response header. Mitigation: 2.2.x users should either apply the patch available at https://www.apache.org/dist/httpd/patches/apply_to_2.2.32/CVE-2017-7679.patch or upgrade in the future to 2.2.33, which is currently unreleased. 2.4.x users should upgrade to 2.4.26. Credit: The Apache HTTP Server security team would like to thank ChenQin and Hanno Böck for reporting this issue. References: https://httpd.apache.org/security_report.html
CVE-2017-3167: ap_get_basic_auth_pw authentication bypass
CVE-2017-3167: ap_get_basic_auth_pw authentication bypass Severity: Important Vendor: The Apache Software Foundation Versions Affected: httpd 2.2.0 to 2.2.32 httpd 2.4.0 to 2.4.25 Description: Use of the ap_get_basic_auth_pw() by third-party modules outside of the authentication phase may lead to authentication requirements being bypassed. Mitigation: 2.2.x users should either apply the patch available at https://www.apache.org/dist/httpd/patches/apply_to_2.2.32/CVE-2017-3167.patch or upgrade in the future to 2.2.33, which is currently unreleased. 2.4.x users should upgrade to 2.4.26. Third-party module writers SHOULD use ap_get_basic_auth_components(), available in 2.2.33 and 2.4.26, instead of ap_get_basic_auth_pw(). Modules which call the legacy ap_get_basic_auth_pw() during the authentication phase MUST either immediately authenticate the user after the call, or else stop the request immediately with an error response, to avoid incorrectly authenticating the current request. Credit: The Apache HTTP Server security team would like to thank Emmanuel Dreyfus for reporting this issue. References: https://httpd.apache.org/security_report.html
Re: [VOTE] Release Apache httpd 2.4.26 as GA
Slightly late to the party, but [x] +1: Good to go Ubuntu 16.04 x64: test suites for httpd and mod_websocket pass with APR 1.5.2, APR-Util 1.5.4 OpenSSL 1.0.2g (Debian patched) mpm_event, mpm_prefork, mpm_worker mod_websocket 0.1.1 I didn't test brotli or PHP. The prefork tests intermittently run into PR 23238's segfault [1]. --Jacob [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=23238
Re: ocsp stapling improvements
On 06/12/2017 08:25 AM, Stefan Eissing wrote: On 4, it seems, we lack a good http(s) client. The code we use for proxying is not easily reused for new connections, or? I see more need for such a thing in the near future. Did the Apache-Serf-for-proxying effort end up going anywhere? I seem to remember Jim working on something related to this point. --Jacob
Re: HTTP/2 and no-longer "experimental"
On 05/31/2017 08:11 AM, Graham Leggett wrote: +1 to no-longer-experimental. +1 to RTC. +1 to both. --Jacob
Re: svn commit: r1707087 - /httpd/httpd/trunk/modules/debugging/mod_bucketeer.c
On 05/02/2017 10:14 AM, Ruediger Pluem wrote> On 04/28/2017 10:50 PM, Jacob Champion wrote: ...why does the EOR bucket have memory ownership of a request_rec, especially when its lifetime is not well defined? And why have we put business logic into a finalizer? This is ringing all of my memory management alarm bells. This dates back to a long time ago (http://svn.apache.org/viewvc?view=revision&revision=327925) when we started to add async processing to httpd. We had the issue that we could not just destroy the request pool, once we "finished" the processing of a request, because we could still have buckets and data created out of the request pool in the async processing of the filters. Hence the idea was to sent a special final request bucket as the very last bucket of a request that tells the filter that consumes the bucket (usually the core output filter) that no data for the request is coming down the filter stack and that it is now save to destroy the request pool. And in order to prevent that logic to be coded in the filter (when it just sees the bucket) it was put in the "finalizer" code of the eor bucket. You might find this strange, but IMHO we have this pattern to use cleanups for some business logic quite often in httpd and we tie a lot of this logic to the lifecycle of pools. So pools are not just a memory management tool, but also a lifecycle management tool. Hi Rüdiger, I just realized I hadn't responded to this; sorry! Thanks for the background. I have been trying (slowly) to learn enough about the async processing chain to participate meaningfully in this discussion, but so far I haven't had the time to really dig in. My intuition is that, if pieces of the request are disappearing out from under the thread, something is wrong with the lifecycle dependency chain (and I've never seen finalizer dependencies work out very well in practice). But it's just an idle guess without more research. AFAIK, this is one of the final blockers (if not *the* final blocker, fingers crossed) for the trunk autotesting system; hence my interest. --Jacob
Re: The drive for 2.4.26
On 05/29/2017 10:52 PM, Jan Ehrhardt wrote: Jan Ehrhardt in gmane.comp.apache.devel (Tue, 30 May 2017 07:13:41 +0200): Steffen in gmane.comp.apache.devel (Mon, 29 May 2017 15:42:46 +0200): Cmake is now Windows only, is that the goal ? In what way is it Windows only? To answer my own question: because of the use of specific Windows only extensions like .lib and names like libaprutil-1.lib. Many (all?) of these can be overridden in the CMake config options, so there is a chance it already works on other OS's. I would be surprised if it did; I thought the main goal of the CMake build was to provide an alternative to the .dsp files, for Windows only. See README.cmake. --Jacob
Experimental C unit test suite available for hacking
Hi all, Last week I had a personal hackathon since I couldn't make it out to ApacheCon. As a result there is now a C-language unit test suite available in branches/httpdunit (based on trunk). I've tested it with a Windows+CMake toolchain as well as an Ubuntu+autoconf toolchain. The suite itself is based on Check, which is a testing library I've had some success with in the past. It's supported on a wide variety of platforms and has a nice feature of running each test in a separate process space, so a crash doesn't derail the entire suite. (Note: Check is LGPL.) The build system has been augmented slightly to generate some of the more tedious boilerplate code. If you want to give it a try, just install Check (and, if using the configure scripts, make sure Check is visible via pkg-config). The test suite will then automatically be added to the default targets. Once everything builds you just run the suite directly with $ ./test/httpdunit As a Check binary, it has multiple knobs to control which tests run and how the reporting is done, but by default it just runs all the tests and prints TAP to stdout. The example tests that are currently running are testing a new API for strict Base64 decoding. Right now it's a feature without a client; I included it here because it was a good showcase of the test suite (see test/unit/base64.c for the test case code). Let me know what you think! --Jacob
Re: Ideas from ApacheCon
On 05/18/2017 10:46 AM, Jim Jagielski wrote: Based on feedback from various sessions: Thanks for the list, Jim! o Warn if the trailing '/'s don't match in ProxyPass/Reverse directives (eg: ProxyPass /foo http://www.example.com/foo/ ) This one is easy enough to put into the directives themselves, but I'd like to expand on the idea in general. What would you all think about a linter for httpd config files? Something that can be updated independently of httpd releases with a ruleset, and that can target multiple versions of the server at once so that everyone gets the benefits without having to upgrade. Ideally the output would be standardized to the point that IDEs could dynamically run the linter as you typed. I started playing with this idea last year but got pulled into security and testing, so I haven't taken a look at my (Python-and-Atom-based) project in a while. This trailing-slash warning was in my notes, as were things like - Unused/unnecessary / - VirtualHosts declared with hostnames instead of IP - Location blocks in the wrong order - Duplicate Listen directives etc. Short term, this helps automate spreading the wisdom that we have to impart over and over again on the support channels. In the long term, linter rulesets document what's difficult about the configuration language so we can potentially design a better one in the future. --Jacob
Re: The drive for 2.4.26
On 04/20/2017 01:06 PM, Gregg Smith wrote: This is ApacheBench, Version 2.3 <$Revision: 1750960 $> Same result with trunk, it just hangs. Glad it's not just Windows! Gregg, did Rainer's patch work for you on Windows? Looks like it hasn't been pushed into trunk yet, so I'll apply it today and will be proposing for backport. --Jacob
Re: ACNA Miami: Who? When?
On 05/08/2017 11:00 AM, Jim Riggs wrote: So, who all will be in Miami? From what I've seen on Sched and messages here: Yes : jimjag, rich, jfc, ruggeri, me No : rowe, covener I won't be able to make it again this year, unfortunately. I'm holding out hope for ACEU. Also, contrary to the seeming consensus on the hackathon thread a couple weeks ago (that I missed), I have had a lot of luck pounding things out during random hacking sessions or down times at the conference, most notably that mod_cache-thundering-herd-lock-file issue that a group of us really hammered on a couple years back. (It was absolutely killing me at work!) That said, I'm always up for hacking on stuff with people, especially when it's something nagging like that. I love hackathons, and I'd be happy to join in remotely if anyone is interested/motivated! --Jacob
Re: svn commit: r1793940 - in /httpd/docs-build/trunk: deps.xml lib/allmodules.pl
On 05/05/2017 04:42 PM, William A Rowe Jr wrote: I've been similarly confused. It's obvious that the XML sources have no context without the XSLT and build stack. For XSLT, agreed. But as Andre points out there is a way to use the XML without the build stack, as long as you have a capable browser. There are a couple ways we could slice this, including pulling .XML out from all the packages which won't ship the transformations. I'm kind of hoping for the opposite of this -- push more of the context that belongs with the XML files into the httpd repo, and remove anything from the build repo that shouldn't be generalized to all branches of the documentation. --Jacob
Re: Change from ad-hoc/historical security process to ASF process?
On 05/05/2017 01:32 PM, Jim Jagielski wrote: +1... Lets do it. BTW, I would adjust #16 to include: Add the CVE to the CHANGES file. That way, it's still documented in CHANGES, just after the release is spun out, show it shows up in the next release's CHANGES. Sounds good to me. --Jacob
Re: Change from ad-hoc/historical security process to ASF process?
On 05/05/2017 05:39 AM, Eric Covener wrote: Here is the change that probably has the biggest impact to the community: """ ... The project team commits the fix. No reference should be made to the commit being related to a security vulnerability. This is the only part that makes me nervous, since I worry it'll encourage obscure commits, but otherwise... To me, this is just a way to get us out of ambiguity/stalemate about the overall process and follow security@a.o's best practices. Thoughts? ...I'm +1 to adopting the standard process in its entirety. We can always modify pieces later if they end up not working for us. --Jacob
Re: svn commit: r1793940 - in /httpd/docs-build/trunk: deps.xml lib/allmodules.pl
[Re-cc'ing docs. Sorry.] On 05/05/2017 01:34 AM, André Malo wrote: Well... It was a split-project back then (in CVS even... :-)). I'm also not sure we want all those jar files and stuff in the main repo. Most people neither use nor need it. I don't mind having the binaries in a separate place, so much as I mind having the text-based stuff there that's tightly coupled to the rest of the documentation and code. What we have right now is equivalent to putting your project's Makefile into a separate repository and then trying to make sure it works correctly for every branch at once. Note that once the changes are finalized, you can run `build tools` and upload the package to dist/docs Ah, so there's a dist package for people who can't check out docs-build? If we moved some files out of docs-build into httpd, would that affect them negatively? To put it another way: if we were to move all the text files and scripts from the docs-build root directory into a docs/manual/build folder in httpd, and left the docs-build lib folder that has all the third-party dependencies and jars and stuff (so that you still had to sync that down from SVN), would there be any downsides compared to today? --Jacob
Re: svn commit: r1793940 - in /httpd/docs-build/trunk: deps.xml lib/allmodules.pl
On 05/05/2017 01:34 AM, André Malo wrote: Well... It was a split-project back then (in CVS even... :-)). I'm also not sure we want all those jar files and stuff in the main repo. Most people neither use nor need it. I don't mind having the binaries in a separate place, so much as I mind having the text-based stuff there that's tightly coupled to the rest of the documentation and code. What we have right now is equivalent to putting your project's Makefile into a separate repository and then trying to make sure it works correctly for every branch at once. Note that once the changes are finalized, you can run `build tools` and upload the package to dist/docs Ah, so there's a dist package for people who can't check out docs-build? If we moved some files out of docs-build into httpd, would that affect them negatively? To put it another way: if we were to move all the text files and scripts from the docs-build root directory into a docs/manual/build folder in httpd, and left the docs-build lib folder that has all the third-party dependencies and jars and stuff (so that you still had to sync that down from SVN), would there be any downsides compared to today? --Jacob
Re: svn commit: r1793940 - in /httpd/docs-build/trunk: deps.xml lib/allmodules.pl
[crossposting dev@ and docs@] On 05/04/2017 04:55 PM, jchamp...@apache.org wrote: Author: jchampion Date: Thu May 4 23:55:48 2017 New Revision: 1793940 URL: http://svn.apache.org/viewvc?rev=1793940&view=rev Log: override index: add deps and exclude from all-modules list I found it a little weird that the XSLT dependencies aren't part of the httpd project, but exist in a separate repo... it doesn't seem like 2.x.y and trunk should be required to have the same dependency graph, or even the same processing scripts. And anyone who forgets to do an `svn up` in their build directory is likely to break things after my commits today. Would there be any interest here in bringing parts of the docs-build repo back into the fold? (Or a history lesson into why things are this way?) --Jacob
Re: Fixing more OpenSSL callback crashes
On 05/04/2017 09:39 AM, Jacob Champion wrote: On 05/04/2017 09:36 AM, William A Rowe Jr wrote: Ugh... This suggests we've further broken crosscompile, just noticed this based on your comment. Why? Cross-compilation uses the same fallback mechanism. To expand on this, there are three choices for implementation for older (pre-1.1.0) OpenSSLs: - Builtin (optimal on some platforms, nonexistent or unsafe on others) - Deprecated (but believed safe enough for most) - Dangerous (but still apparently good enough for a bunch of people?) Builtin is only used if we can *prove* that the builtin implementation is available and safe. Some environments (Windows + 1.0.x) are known to have safe builtins; everyone else has to run a test. If we can't run that test for any reason, we fall back to the Deprecated implementation. If that API is no longer available (e.g. OPENSSL_NO_DEPRECATED is in use), we have no choice but to use the Dangerous implementation. So since we can't run a test executable on a cross-compile target, if you're cross-compiling to a platform that isn't "known safe", we'll fall back to the Deprecated implementation if it's available. That choice can be overridden with a cachevar, if you know your platform guarantees safety -- ac_cv_openssl_use_errno_threadid in this case. --Jacob
Re: Fixing more OpenSSL callback crashes
On 05/04/2017 09:36 AM, William A Rowe Jr wrote: Ugh... This suggests we've further broken crosscompile, just noticed this based on your comment. Why? Cross-compilation uses the same fallback mechanism. If a user doesn't like the conservative choice, he/she should set the cachevars to override the defaults, per usual. (If you find that my system *doesn't* work for cross-compilation, please let me know; that's a bug. :D But I did have it in mind when I wrote it.) --Jacob
Re: Fixing more OpenSSL callback crashes
On 05/03/2017 11:25 PM, Ruediger Pluem wrote: Just as a heads up as I currently don't have time to investigate further. I get the below on CentOS 6.9 64 bit, which puzzles me a little bit as I would expect the errno addresses to be different in different threads on my OS. [Thu May 04 06:17:13.723918 2017] [ssl:notice] [pid 2629:tid 140039001335552] AH10028: using deprecated CRYPTO_set_id_callback for OpenSSL OpenSSL used is the one delivered by CentOS: openssl-1.0.1e-57.el6.x86_64 Do you use an installed APR or build using --with-included-apr? The configure test that determines whether your errno is safe has to be linked against an already-built APR; otherwise the fallbacks come into play. --Jacob
Re: SSL and Usability and Safety
On 05/02/2017 02:10 PM, Eric Covener wrote: I think to be useful, reasonable SSL defaults have to be subject to change in maintenance (and over-rideable) So... this got me thinking. If we put this new "stuff" (whatever it turns out to be) into a new directive, - part of its operation gets tied to source code that's hidden from the end user - we'll probably have to duplicate some SSL directive logic in the module - we have to figure out the merge/conflict scenarios, which -- while definitely worthwhile in the long term -- feels likely to add complexity to the short-term discussion If all of the settings that are part of this new directive can be described in terms of other already-existing directives, could we implement it as a server-owned Macro? - their implementation is public and auditable by anyone who understands the config syntax - they can be easily patched for vulnerabilities without recompiling anything - merge/conflict resolution will follow the individual directives' current merge logic (whatever that happens to be) We could reserve a macro prefix (or symbol) for the server and its modules so that we don't step on anyone with future expansion. Then it's just a matter of Include macros/ssl.conf Use !SslIntermediateSecuritySettings We'd have to be very explicit that the macro definitions belong to the server distribution, and installing a newer (or older) version of the server would overwrite whatever changes you'd made to those macro files. Thoughts? --Jacob
Re: SSL and Usability and Safety
On 05/02/2017 02:01 PM, Helmut K. C. Tessarek wrote: I'm not sure, how much perf difference there is between A, B, and C, but SSL by itself has quite an impact (For the record, our bucket brigade implementation is currently hamstringing our TLS static file performance, and on top of that OpenSSL is doing an awful lot of memcpy's that might(?) not be necessary, so we have to be careful when declaring "TLS has an impact" vs "our implementation has an impact when TLS is enabled".) But otherwise agreed: relative performance would be another great thing to document for these settings. --Jacob
Re: SSL and Usability and Safety
On 05/02/2017 11:48 AM, William A Rowe Jr wrote: Are you referring to mod_ssl or a number of modules? If we find such things, 2.next is our chance to correct any and all unexpected merge behaviors. A number of them, but it's less "there are bugs" and more "every directive/module does its own thing". Are directives merged in file order? least-to-most-specific container order? breadth-first order across all containers (e.g. the new nested )? When conflicting directives are found, are they merged in some way, or is one just silently dropped? Stuff like that. It's mostly off-topic for this thread, but if there's interest in a broader discussion, I can start one. --Jacob
