Re: Question about APR trunk and httpd ldap modules
On Thu, May 27, 2021, 07:52 Eric Covener wrote: > On Thu, May 27, 2021 at 8:45 AM Rainer Jung > wrote: > > > is my understanding correct, that even httpd trunk (and then also 2.4.x) > > needs LDAP support in APR/APU to build mod_ldap and mod_authnz_ldap? > > > > So since we removed LDAP support from APR trunk, that means those > > modules currently can not be build using APR trunk, neither in httpd > > trunk nor in httpd 2.4.x. Correct? > > I think this is correct. This was a pretty heated/sore issue to my > recollection. Only the removal got done. > That's nearly correct. The port to ap_ namespace was composed and committed to httpd trunk, by myself. And in the heat of the argument, vetoed by the obvious party, so I reasonably promptly reverted that, without a few minor tweaks that were still necessary across various platforms or httpd build scenarios. But you can find nearly all the necessary work on httpd trunk history, if there's a desire to ressurect the ability for httpd to survive an apr 2 release. It didn't matter for PCRE, so I don't know that it is a priority. Any discussion w.r.t. apr project belongs at that project, if there's a desire to cause some action there. Based on observations of the huge scale of Curl vulnerabilities (which hit us for mod_md, because that is libcurl, as opposed to serf or something straightforward as the letsenrypt client), and on some additional thoughts shared on apr about further modularizing and disconnecting the each-and-every-facility from core apr+util, that would be an interesting discussion to have. But it might have even more additional resistance based on today's security postures, based on dependencies of dependencies security history.
Re: Contribution to Apache HTTPD
I'm a different person. Although my name is the same. But I've studied PHP internals thoroughly (for my personal and professional needs). So I understand them well too. Perhaps, I may be useful to the community. On Thu, May 27, 2021 at 7:50 PM Jan Ehrhardt wrote: > > Hi nikic, > > Nikita Popov in gmane.comp.apache.devel (Thu, 27 May 2021 17:52:27 +0500): > >Hello. I'm a senior C developer working for CloudLinux. I would like > >to participate in the HTTPD project. Are there any unassigned tasks > >which I can take? And how to proceed with it? Thanks in advance. > > Nice to meet you here. For the others: highly recommended Open Source > developer. One of the very few who know almost everything about PHP > Internals. Get him on board. > -- > Jan >
Re: Contribution to Apache HTTPD
Hello and welcome! I'm sure others may give better advice than me since I'm no dev but have you checked http://httpd.apache.org/dev/ yet? There is a lot of info there that I think it is worth checking to get started. Cheers! El jue, 27 may 2021 a las 14:52, Nikita Popov () escribió: > > Hello. I'm a senior C developer working for CloudLinux. I would like > to participate in the HTTPD project. Are there any unassigned tasks > which I can take? And how to proceed with it? Thanks in advance. -- Daniel Ferradal HTTPD Project #httpd help at Libera.Chat
Re: Contribution to Apache HTTPD
Hi nikic, Nikita Popov in gmane.comp.apache.devel (Thu, 27 May 2021 17:52:27 +0500): >Hello. I'm a senior C developer working for CloudLinux. I would like >to participate in the HTTPD project. Are there any unassigned tasks >which I can take? And how to proceed with it? Thanks in advance. Nice to meet you here. For the others: highly recommended Open Source developer. One of the very few who know almost everything about PHP Internals. Get him on board. -- Jan
Re: Question about APR trunk and httpd ldap modules
On 5/27/21 2:52 PM, Eric Covener wrote: > On Thu, May 27, 2021 at 8:45 AM Rainer Jung wrote: > >> is my understanding correct, that even httpd trunk (and then also 2.4.x) >> needs LDAP support in APR/APU to build mod_ldap and mod_authnz_ldap? >> >> So since we removed LDAP support from APR trunk, that means those >> modules currently can not be build using APR trunk, neither in httpd >> trunk nor in httpd 2.4.x. Correct? > > I think this is correct. This was a pretty heated/sore issue to my > recollection. Only the removal got done. This is my remembrance as well, but this discussion is nearly about 10 years old (https://lists.apache.org/thread.html/71eed505b12bfc9141cd31279e6c97c8984f371cb26342b6496a14a4%401306784907%40%3Cdev.apr.apache.org%3E). Probably worth restarting it. I guess there are two options on the table: 1. Create LDAP support within APR with an API that people can agree on. Of course people do not only need to agree, but the work of doing this would need to be done over at APR land (hopefully by several people to have maintainability). 2. Do all the LDAP stuff in httpd, which of course also requires a proposal for an architecture / API and someone doing this work. Regards Rüdiger
Re: svn commit: r1890245 - in /httpd/httpd/branches/2.4.x: ./ docs/manual/mod/ include/ modules/http2/ server/
Thx! Fixed. > Am 27.05.2021 um 16:07 schrieb Christophe JAILLET > : > > Hi, > > Nitpicking > > CJ > > Le 27/05/2021 à 15:08, ic...@apache.org a écrit : >> Author: icing >> Date: Thu May 27 13:08:21 2021 >> New Revision: 1890245 >> >> URL: http://svn.apache.org/viewvc?rev=1890245&view=rev >> Log: >> Merged >> r1734009,r1734231,r1734281,r1838055,r1838079,r1840229,r1876664,r1876674,r1876784,r1879078,r1881620,r1887311,r171 >> from trunk: >> >> *) core: Split ap_create_request() from ap_read_request(). [Graham Leggett] >> >> *) core, h2: common ap_parse_request_line() and ap_check_request_header() >> code. [Yann Ylavic] >> >> *) core: Add StrictHostCheck to allow unconfigured hostnames to be >> rejected. [Eric Covener] >> >> [...] >> >> Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/core.xml >> URL: >> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/core.xml?rev=1890245&r1=1890244&r2=1890245&view=diff >> == >> --- httpd/httpd/branches/2.4.x/docs/manual/mod/core.xml (original) >> +++ httpd/httpd/branches/2.4.x/docs/manual/mod/core.xml Thu May 27 13:08:21 >> 2021 >> @@ -5207,6 +5207,42 @@ recognized methods to modules. >> >> >> +StrictHostCheck >> +Controls whether the server requires the requested hostname be >> + listed enumerated in the virtual host handling the request >> + >> +StrictHostCheck ON|OFF >> +StrictHostCheck OFF >> +server configvirtual host >> + >> +Added in 2.5.1 > > 2.4.49 > >> [...] >> >> Modified: httpd/httpd/branches/2.4.x/include/ap_mmn.h >> URL: >> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/include/ap_mmn.h?rev=1890245&r1=1890244&r2=1890245&view=diff >> == >> --- httpd/httpd/branches/2.4.x/include/ap_mmn.h (original) >> +++ httpd/httpd/branches/2.4.x/include/ap_mmn.h Thu May 27 13:08:21 2021 >> @@ -559,6 +559,9 @@ >> * and ap_ssl_answer_challenge and hooks. >> * 20120211.104 (2.4.47-dev) Move ap_ssl_* into new http_ssl.h header file >> * 20120211.105 (2.4.47-dev) Add ap_ssl_ocsp* hooks and functions to >> http_ssl.h. >> + * 20120211.106 (2.4.47-dev) Add ap_create_request(). >> + * 20120211.107 (2.4.47-dev) Add ap_parse_request_line() and >> + * ap_check_request_header() >> */ >> > > 2.4.49-dev >
Re: svn commit: r1890245 - in /httpd/httpd/branches/2.4.x: ./ docs/manual/mod/ include/ modules/http2/ server/
Hi, Nitpicking CJ Le 27/05/2021 à 15:08, ic...@apache.org a écrit : Author: icing Date: Thu May 27 13:08:21 2021 New Revision: 1890245 URL: http://svn.apache.org/viewvc?rev=1890245&view=rev Log: Merged r1734009,r1734231,r1734281,r1838055,r1838079,r1840229,r1876664,r1876674,r1876784,r1879078,r1881620,r1887311,r171 from trunk: *) core: Split ap_create_request() from ap_read_request(). [Graham Leggett] *) core, h2: common ap_parse_request_line() and ap_check_request_header() code. [Yann Ylavic] *) core: Add StrictHostCheck to allow unconfigured hostnames to be rejected. [Eric Covener] [...] Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/core.xml URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/core.xml?rev=1890245&r1=1890244&r2=1890245&view=diff == --- httpd/httpd/branches/2.4.x/docs/manual/mod/core.xml (original) +++ httpd/httpd/branches/2.4.x/docs/manual/mod/core.xml Thu May 27 13:08:21 2021 @@ -5207,6 +5207,42 @@ recognized methods to modules. +StrictHostCheck +Controls whether the server requires the requested hostname be + listed enumerated in the virtual host handling the request + +StrictHostCheck ON|OFF +StrictHostCheck OFF +server configvirtual host + +Added in 2.5.1 2.4.49 [...] Modified: httpd/httpd/branches/2.4.x/include/ap_mmn.h URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/include/ap_mmn.h?rev=1890245&r1=1890244&r2=1890245&view=diff == --- httpd/httpd/branches/2.4.x/include/ap_mmn.h (original) +++ httpd/httpd/branches/2.4.x/include/ap_mmn.h Thu May 27 13:08:21 2021 @@ -559,6 +559,9 @@ * and ap_ssl_answer_challenge and hooks. * 20120211.104 (2.4.47-dev) Move ap_ssl_* into new http_ssl.h header file * 20120211.105 (2.4.47-dev) Add ap_ssl_ocsp* hooks and functions to http_ssl.h. + * 20120211.106 (2.4.47-dev) Add ap_create_request(). + * 20120211.107 (2.4.47-dev) Add ap_parse_request_line() and + * ap_check_request_header() */ 2.4.49-dev
Contribution to Apache HTTPD
Hello. I'm a senior C developer working for CloudLinux. I would like to participate in the HTTPD project. Are there any unassigned tasks which I can take? And how to proceed with it? Thanks in advance.
Re: Question about APR trunk and httpd ldap modules
On Thu, May 27, 2021 at 8:45 AM Rainer Jung wrote: > is my understanding correct, that even httpd trunk (and then also 2.4.x) > needs LDAP support in APR/APU to build mod_ldap and mod_authnz_ldap? > > So since we removed LDAP support from APR trunk, that means those > modules currently can not be build using APR trunk, neither in httpd > trunk nor in httpd 2.4.x. Correct? I think this is correct. This was a pretty heated/sore issue to my recollection. Only the removal got done.
Question about APR trunk and httpd ldap modules
Hi there, is my understanding correct, that even httpd trunk (and then also 2.4.x) needs LDAP support in APR/APU to build mod_ldap and mod_authnz_ldap? So since we removed LDAP support from APR trunk, that means those modules currently can not be build using APR trunk, neither in httpd trunk nor in httpd 2.4.x. Correct? Just trying to understand the current situation about APR trunk and its implications. Thanks and regards, Rainer
mod_proxy/mod_ssl interworking
I believe we can improve the current interworking between mod_proxy and mod_ssl somewhat. Without repeating the current dance of calling optional functions here, I see the following things that can be done: 1. Have an "outgoing" flag in conn_rec that makes clear a connection is going from the server to somewhere else. What this achieves is that all pre_connection hooks can easily see they should not apply their incoming configuration for outgoing connections. This would mean for example, that mod_ssl would not try to setup SSL for http: proxy connection that came through an incoming https: server_rec. The explicit "ssl_engine_set(c, 0)" would no longer be needed. 2. Have a new "ap_hook_config_connection(c, per_dir_config)" that runs before "pre_connection" hook to attach the configuration o use for a connection. For connection reuse, this may be invoked more than once on a connection and any previous config attached needs to be discarded. This is needed to replace a r->per_dir_config previously used when r goes out of scope. We could allow the per_dir_config == NULL and call this also for incoming connections. Not sure if this is needed. 3. Have a "require_ssl" flag in conn_rec that makes clear a connection needs to be encrypted. This let's mod_ssl know that it should check the config for the connection if it should engage on it. It also makes clear that a connection - after pre_connection() - with "c->require_ssl" and "ap_ssl_conn_is_ssl(c) == 0" is not valid and needs to be denied. We could set "c->require_ssl = 1" on incoming connections where "Listen https" is configured. That has the potential to break existing configurations out there, so it might not be worth it. If you have an opinion or another idea how to do this, I would very much appreciate to hear it. Based on the feedback I will make start an implementation of this and see if this completely solves the OPTIONAL function dependencies. Thanks, Stefan
https: proxies
Do I read the code correctly that httpd is not able to use https: remote proxies? This might be a somewhat esoteric feature in httpd setups, or it might have become a desirable thing in the "encrypt everything" world. I am not sure. Anyone aware of this? Cheers, Stefan