Re: Align worker's worker's fdqueue with event's?

[Yann Ylavic]

On Thu, Jan 11, 2018 at 1:34 PM, Stefan Eissing
 wrote:
>> Am 11.01.2018 um 13:02 schrieb Yann Ylavic :
>>
>> there a several optimizations and correctness fixes in event/fdqueue.c
>> that don't land in worker/fdqueue.c.
[]
> If we had a single, nice build system, I'd be all for it. With the
> current state of things, I am not sure it is worth our time to
> think about common code that is not in the public API,

At least that'd avoid missing fixes/improvements made in one code and
not the other.
Not sure fixing twice or more isn't what can consume our time too.

>
> Making both files the same, might still be worth it since future
> enhancements can be copied/patched more easily. And there are not
> *that* many people working in this area.

Which also suggests code should be centralized IMO, because new comers
may not know about the duplication and the need to fix in multiple
places.

>
>> For now things that are event only are not aligned (e.g. timers), but
>> ultimately I'd like to have a single fdqueue.[ch] for both MPMs (not
>> too far once this patch is applied), that'd certainly help maintenance
>> and improvements for both.
>> If you agree on this, what would be the best practice/place for the common 
>> code?
>
> Making things part of the API has a high price in back porting costs and
> not being able to take things away again.

I don't mean to make it API, still a private (unix specific/common)
thing, something like "os/unix/unixd.c"'s non-AP_DECLARE things.

>
> Related issues exist in modules too. mod_http2 and mod_proxy_http2 would
> like to share. mod_md once had an executable with shared code.
>
> I eliminated the sharing and the executable rather than having to deal
> with that pain. Not ideal, but there is limited time to put into such
> things.

Yeah, sharing from/between modules (APR_OPTIONAL) is another beast I'd
like to avoid here for 2 "unix" MPMs, hence the core non-AP_DECLARE
(hidden) proposal maybe.


Thanks,
Yann.

can we haz backports?

[Stefan Eissing]

Team,

the frequency that people keep on asking me when ACME 
support in Apache will be released is going up. For 
this to happen, two backports need 1(!) more vote:

1. core/mod_ssl: Add new flag int to module struct.
 existing votes: icing, ylavic
2. mod_md: backport of ACME (Let's Encrypt) support. 
 existing votes: icing, jim

Is anyone planning to review this in the next days? Maybe,
since everyone has limited time, coordinating this might
be helpful?

Hoping to hear back from you.

Cheers,

Stefan

Re: can we haz backports?

[Steffen]

Now mod_md contains features which are not supported anymore ! 

For SSL only config mod_md is not usable anymore, see 
https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188
 

Propose to change mod_md regarding above, now I vote -1. 

On windows I advise LE-Win-Simple with its selfhosting option when you have SSL 
only. 



> Op 12 jan. 2018 om 12:14 heeft Stefan Eissing  
> het volgende geschreven:
> 
> Team,
> 
> the frequency that people keep on asking me when ACME 
> support in Apache will be released is going up. For 
> this to happen, two backports need 1(!) more vote:
> 
> 1. core/mod_ssl: Add new flag int to module struct.
> existing votes: icing, ylavic
> 2. mod_md: backport of ACME (Let's Encrypt) support. 
> existing votes: icing, jim
> 
> Is anyone planning to review this in the next days? Maybe,
> since everyone has limited time, coordinating this might
> be helpful?
> 
> Hoping to hear back from you.
> 
> Cheers,
> 
> Stefan
> 
> 

Re: Align worker's worker's fdqueue with event's?

[Yann Ylavic]

A bit orthogonal, I'd also like to sync 2.4.x "event" with trunk's
w.r.t. cosmetic changes before (and to help) further backport
proposals.

That's possibly something that'll help *us* for later backports, but
not necessarily distros with (security-)fixes only policy.
Is that something we should more care about? I suppose distro
maintainers do care...

For instance, the three attached patches are how I would stage latest
"event" changes in 2.4.x:
- patch 1: align with trunk what can/needs to be (cosmetics);
- patch 2: optimizations and correctness which don't seem to have
bitten us so far (not a proven fix someow);
- patch 3: a wakeup fix (corner case) that applies almost cleanly
thanks to 1/ and 2/.

Would this work or should I go with 3/ directly and resolve backport
conflicts there?
Or maybe go with 3/ then 2/ then 1/, for the same result but at least
distros would care of the first step only (for this time...)?
Merge r1605328, r1629576 from trunk:

event: minify local variables scope.

event: have_idle_worker must not be cleared in every listener_thread iteration.
Fixes bug when workers were not stopped after graceful restart (introduced in
r1605328).

Submitted by: takashi, jkaluza

diff --git a/server/mpm/event/event.c b/server/mpm/event/event.c
index 54c9256074..1a5f70e55c 100644
--- a/server/mpm/event/event.c
+++ b/server/mpm/event/event.c
@@ -1545,22 +1545,14 @@ static void process_keepalive_queue(apr_time_t timeout_time)
 
 static void * APR_THREAD_FUNC listener_thread(apr_thread_t * thd, void *dummy)
 {
-timer_event_t *te;
 apr_status_t rc;
 proc_info *ti = dummy;
 int process_slot = ti->pslot;
 struct process_score *ps = ap_get_scoreboard_process(process_slot);
 apr_pool_t *tpool = apr_thread_pool_get(thd);
-void *csd = NULL;
-apr_pool_t *ptrans; /* Pool for per-transaction stuff */
-ap_listen_rec *lr;
-int have_idle_worker = 0;
-const apr_pollfd_t *out_pfd;
-apr_int32_t num = 0;
-apr_interval_time_t timeout_interval;
-apr_time_t timeout_time = 0, now, last_log;
-listener_poll_type *pt;
 int closed = 0, listeners_disabled = 0;
+int have_idle_worker = 0;
+apr_time_t last_log;
 
 last_log = apr_time_now();
 free(ti);
@@ -1581,6 +1573,11 @@ static void * APR_THREAD_FUNC listener_thread(apr_thread_t * thd, void *dummy)
 apr_signal(LISTENER_SIGNAL, dummy_signal_handler);
 
 for (;;) {
+timer_event_t *te;
+const apr_pollfd_t *out_pfd;
+apr_int32_t num = 0;
+apr_interval_time_t timeout_interval;
+apr_time_t now, timeout_time;
 int workers_were_busy = 0;
 
 if (listener_may_exit) {
@@ -1693,7 +1690,7 @@ static void * APR_THREAD_FUNC listener_thread(apr_thread_t * thd, void *dummy)
 }
 
 while (num) {
-pt = (listener_poll_type *) out_pfd->client_data;
+listener_poll_type *pt = (listener_poll_type *) out_pfd->client_data;
 if (pt->type == PT_CSD) {
 /* one of the sockets is readable */
 event_conn_state_t *cs = (event_conn_state_t *) pt->baton;
@@ -1785,7 +1782,9 @@ static void * APR_THREAD_FUNC listener_thread(apr_thread_t * thd, void *dummy)
 enable_listensocks(process_slot);
 }
 if (!listeners_disabled) {
-lr = (ap_listen_rec *) pt->baton;
+void *csd = NULL;
+ap_listen_rec *lr = (ap_listen_rec *) pt->baton;
+apr_pool_t *ptrans; /* Pool for per-transaction stuff */
 ap_pop_pool(&ptrans, worker_queue_info);
 
 if (ptrans == NULL) {
@@ -1968,12 +1967,8 @@ static void *APR_THREAD_FUNC worker_thread(apr_thread_t * thd, void *dummy)
 proc_info *ti = dummy;
 int process_slot = ti->pslot;
 int thread_slot = ti->tslot;
-apr_socket_t *csd = NULL;
-event_conn_state_t *cs;
-apr_pool_t *ptrans; /* Pool for per-transaction stuff */
 apr_status_t rv;
 int is_idle = 0;
-timer_event_t *te = NULL;
 
 free(ti);
 
@@ -1984,6 +1979,11 @@ static void *APR_THREAD_FUNC worker_thread(apr_thread_t * thd, void *dummy)
 SERVER_STARTING, NULL);
 
 while (!workers_may_exit) {
+apr_socket_t *csd = NULL;
+event_conn_state_t *cs;
+timer_event_t *te = NULL;
+apr_pool_t *ptrans; /* Pool for per-transaction stuff */
+
 if (!is_idle) {
 rv = ap_queue_info_set_idle(worker_queue_info, NULL);
 if (rv != APR_SUCCESS) {
@@ -2007,7 +2007,6 @@ static void *APR_THREAD_FUNC worker_thread(apr_thread_t * thd, void *dummy)
 break;
 }
 
-te = NULL;
 rv = ap_queue_pop_something(worker_queue, &csd, &cs, &ptrans, &te);
 
 if (rv != APR_SUCCESS) {
Merge r1643279, r1703241, r1802535, r1819847, r1819848, r1819852, r1819853 from trunk:

mpm_even

Re: can we haz backports?

[Stefan Eissing]

> Am 12.01.2018 um 12:32 schrieb Steffen :
> 
> Now mod_md contains features which are not supported anymore ! 
> 
> For SSL only config mod_md is not usable anymore, see 
> https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188
>  
> 
> Propose to change mod_md regarding above, now I vote -1.

You want to veto the backport? Really? I think the project deserves
a more detailed rationale for such a decision.

> On windows I advise LE-Win-Simple with its selfhosting option when you have 
> SSL only. 

This is not one or the other. We also support several mpm modules, based
on individual needs.

If you have a personal grudge against me, the project and its product is
a poor way to play it out. You let everyone who wants to make good use
of mod_md, and there are people asking, suffer because it does not do what 
you personally need on your site? What egocentric logic is that?

For the record: mod_md is one of the ACME clients that behaves gracefully under
the recent TLS-SNI disable and people who have port 80 open, have to do
nothing for the certificate renewal/signup to continue working.

If you want to improve any Apache functionality, provide code changes
or, at least, constructive feedback. You are not here to sit on the 
fence and snipe at people's work.

-Stefan


> Op 12 jan. 2018 om 12:14 heeft Stefan Eissing  
> het volgende geschreven:
> 
>> Team,
>> 
>> the frequency that people keep on asking me when ACME 
>> support in Apache will be released is going up. For 
>> this to happen, two backports need 1(!) more vote:
>> 
>> 1. core/mod_ssl: Add new flag int to module struct.
>> existing votes: icing, ylavic
>> 2. mod_md: backport of ACME (Let's Encrypt) support. 
>> existing votes: icing, jim
>> 
>> Is anyone planning to review this in the next days? Maybe,
>> since everyone has limited time, coordinating this might
>> be helpful?
>> 
>> Hoping to hear back from you.
>> 
>> Cheers,
>> 
>> Stefan
>> 
>> 

Re: can we haz backports?

[Yann Ylavic]

On Fri, Jan 12, 2018 at 12:32 PM, Steffen  wrote:
> Now mod_md contains features which are not supported anymore !
>
> For SSL only config mod_md is not usable anymore, see
> https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188

This link refers to a certbot plugin to test httpd, does it mean testing mod_md?
Doesn't the test pass?


Regards,
Yann.

Re: can we haz backports?

[Yann Ylavic]

On Fri, Jan 12, 2018 at 12:14 PM, Stefan Eissing
 wrote:
>
> Is anyone planning to review this in the next days?

I plan to do so, is there a strong need to own a domain for tesing or
can I use a "standalone" thingy (if that's ever relevant)?

Re: can we haz backports?

[Stefan Eissing]

> Am 12.01.2018 um 13:07 schrieb Yann Ylavic :
> 
> On Fri, Jan 12, 2018 at 12:14 PM, Stefan Eissing
>  wrote:
>> 
>> Is anyone planning to review this in the next days?
> 
> I plan to do so, is there a strong need to own a domain for tesing or
> can I use a "standalone" thingy (if that's ever relevant)?

If you go against the staging server at Let's Encrypt, any
challenge for a domain name will need to be resolved to an IP
address that you listen on. This will give you a certificate
on success that has an untrusted root, but you can request
that for the domain very often, as needed in testing.

You can test locally. The LE ACME server is available as a
docker instance, as described in https://github.com/letsencrypt/boulder

That is the one the test suite in https://github.com/icing/mod_md uses.

-Stefan

Re: can we haz backports?

[Eric Covener]

On Fri, Jan 12, 2018 at 6:32 AM, Steffen  wrote:
> Now mod_md contains features which are not supported anymore !
>
> For SSL only config mod_md is not usable anymore, see
> https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188
>
> Propose to change mod_md regarding above, now I vote -1.

What do you propose to be changed?  Most of us aren't following this
space very closely.

Re: can we haz backports?

[Eric Covener]

On Fri, Jan 12, 2018 at 6:14 AM, Stefan Eissing
 wrote:
> Team,
>
> the frequency that people keep on asking me when ACME
> support in Apache will be released is going up. For
> this to happen, two backports need 1(!) more vote:
>
> 1. core/mod_ssl: Add new flag int to module struct.
>  existing votes: icing, ylavic
> 2. mod_md: backport of ACME (Let's Encrypt) support.
>  existing votes: icing, jim
>
> Is anyone planning to review this in the next days? Maybe,
> since everyone has limited time, coordinating this might
> be helpful?
>
> Hoping to hear back from you.

I'll be able to make a dent in these today.

Re: can we haz backports?

[Yann Ylavic]

On Fri, Jan 12, 2018 at 12:32 PM, Steffen  wrote:
>
> Propose to change mod_md regarding above, now I vote -1.

Could you please elaborate on what isn't working for Windows/you?
Is it a general failure for Windows users or something that can be
addressed as follow up?

I don't doubt Stefan will address any failure, maybe a matter of
priority, he does a great/hard/busy work already.
All cannot just be done now and in a one go for the first release,
don't you think?

Regards,
Yann.

Re: Align worker's worker's fdqueue with event's?

[Eric Covener]

On Fri, Jan 12, 2018 at 6:51 AM, Yann Ylavic  wrote:
> A bit orthogonal, I'd also like to sync 2.4.x "event" with trunk's
> w.r.t. cosmetic changes before (and to help) further backport
> proposals.
>
> That's possibly something that'll help *us* for later backports, but
> not necessarily distros with (security-)fixes only policy.
> Is that something we should more care about? I suppose distro
> maintainers do care...
>
> For instance, the three attached patches are how I would stage latest
> "event" changes in 2.4.x:
> - patch 1: align with trunk what can/needs to be (cosmetics);
> - patch 2: optimizations and correctness which don't seem to have
> bitten us so far (not a proven fix someow);
> - patch 3: a wakeup fix (corner case) that applies almost cleanly
> thanks to 1/ and 2/.
>
> Would this work or should I go with 3/ directly and resolve backport
> conflicts there?
> Or maybe go with 3/ then 2/ then 1/, for the same result but at least
> distros would care of the first step only (for this time...)?

Looks reasonable to me, better to rip the band-aid off then pay the
price/risk every time something needs to be backported.

Re: Align worker's worker's fdqueue with event's?

[Ruediger Pluem]

On 01/12/2018 01:32 PM, Eric Covener wrote:
> On Fri, Jan 12, 2018 at 6:51 AM, Yann Ylavic  wrote:
>> A bit orthogonal, I'd also like to sync 2.4.x "event" with trunk's
>> w.r.t. cosmetic changes before (and to help) further backport
>> proposals.
>>
>> That's possibly something that'll help *us* for later backports, but
>> not necessarily distros with (security-)fixes only policy.
>> Is that something we should more care about? I suppose distro
>> maintainers do care...
>>
>> For instance, the three attached patches are how I would stage latest
>> "event" changes in 2.4.x:
>> - patch 1: align with trunk what can/needs to be (cosmetics);
>> - patch 2: optimizations and correctness which don't seem to have
>> bitten us so far (not a proven fix someow);
>> - patch 3: a wakeup fix (corner case) that applies almost cleanly
>> thanks to 1/ and 2/.
>>
>> Would this work or should I go with 3/ directly and resolve backport
>> conflicts there?
>> Or maybe go with 3/ then 2/ then 1/, for the same result but at least
>> distros would care of the first step only (for this time...)?
> 
> Looks reasonable to me, better to rip the band-aid off then pay the
> price/risk every time something needs to be backported.
> 

+1

Regards

Rüdiger

Re: Align worker's worker's fdqueue with event's?

[Eric Covener]

> I don't mean to make it API, still a private (unix specific/common)
> thing, something like "os/unix/unixd.c"'s non-AP_DECLARE things.

seems like there should be no big surprises here with analogs like
unixd, mpm_common, etc

Re: can we haz backports?

[Steffen]

Re: can we haz backports?

[Eric Covener]

On Fri, Jan 12, 2018 at 7:38 AM, Steffen  wrote:
> Yann: it is not working (anymore) when you have only port 443 open.
> Yann: I am/was testing in real live, no boulder.
> Eric: proposed change:  to begin with warns/errors user
>
> I am talking about SSL configurations without port 80 open. It is not an
> individual issue, there are more around with no port 80 open. So it is not
> only for me !!!
>

Sounds like a minor documentation issue for the current limitation in
some configurations.

Generally, we don't use -1 for something like that. Although not all
-1's are actually "vetoes" -- it is still reserved for something
actively detrimental.

Re: can we haz backports?

[Eric Covener]

> Generally, we don't use -1 for something like that. Although not all
> -1's are actually "vetoes" -- it is still reserved for something
> actively detrimental.

Whoops, they are actuallt vetoes for code or backports.

Re: can we haz backports?

[Ruediger Pluem]

On 01/12/2018 01:50 PM, Eric Covener wrote:
> On Fri, Jan 12, 2018 at 7:38 AM, Steffen  wrote:
>> Yann: it is not working (anymore) when you have only port 443 open.
>> Yann: I am/was testing in real live, no boulder.
>> Eric: proposed change:  to begin with warns/errors user
>>
>> I am talking about SSL configurations without port 80 open. It is not an
>> individual issue, there are more around with no port 80 open. So it is not
>> only for me !!!
>>
> 
> Sounds like a minor documentation issue for the current limitation in
> some configurations.
> 
> Generally, we don't use -1 for something like that. Although not all
> -1's are actually "vetoes" -- it is still reserved for something
> actively detrimental.
> 

While I guess it is neither official nor documented I think best practice for 
cases of a strong opinion but no veto is
to use either

-1 (no veto)

or

-0.5

That's at least what I have seen and what I would do in such cases.

Regards

Rüdiger

Re: can we haz backports?

[Stefan Eissing]

I try a high level, short summary of the current ACME "TLS-SNI" issue:

1. There are 3 basic ways to verify domain ownership:
  a) "http-01" on port 80
 requests /.well-known/acme-challenge/
 response: signed token as base64url
  b) "tls-sni-01" on port 443
 client hello with SNI for ".acme.invalid"
 serverhello with matching, self-signed certificate
  c) "dns-01" where you provide a signed challenge at a
 acme-challenge.your-domain TEXT entry underneath your
 domain.

a) and b) are supported by mod_md. Which method is actually used
depends on 
  - what the ACME server offers, for each dns ownship check it
sends the list of available challenges
 - what the local Apache instance can do, e.g. does it listen
   on the ports required

This week, Lets Encrypt got informed by a security researcher
that challenge b) "tls-sni-01" can be exploited in several shared
hosting environments where customer are allowed to upload self-signed
certificates for domain names of their choice.

Let's Encrypt then immediately disabled "tls-sni-01" and informed
the people on various list and social media about it. Mitigations
are currently discussed. There is a good chance that it might stay
disabled in general, but kept available for already existing accounts.

"Disabled" here means that when asked to verify, the LE ACME server
will no longer offer "tls-sni-01" as challenge method. mod_md
scans this and will use the alternative "http-01", if offered, and
if local port 80 is listened to. If no usable challenge method is
found, an ERROR is logged.

This means that mod_md continues to work for people with port 80
open and will ERROR for instances where only port 443 is available.
There is no way around this.

Other ACME clients can only work around this, when they open port
80 themselves and listen for challenges. Some do, some don't. If
your firewall is blocking 80, none will succeed.

Note, some clients need updates as they do not scan the list 
returned by the server. Some ACM enabled server say they do
not care either but try randomly all methods they know, so eventually
it will succeed. *shrug*

So, our users, if they had the module, would have survived this
quite well, I think. Which is no guarantuee for the future, but still...

Cheers,

Stefan


> Am 12.01.2018 um 13:22 schrieb Eric Covener :
> 
> On Fri, Jan 12, 2018 at 6:32 AM, Steffen  wrote:
>> Now mod_md contains features which are not supported anymore !
>> 
>> For SSL only config mod_md is not usable anymore, see
>> https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188
>> 
>> Propose to change mod_md regarding above, now I vote -1.
> 
> What do you propose to be changed?  Most of us aren't following this
> space very closely.

Re: Align worker's worker's fdqueue with event's?

[Jim Jagielski]

> On Jan 12, 2018, at 7:32 AM, Eric Covener  wrote:
> 
> On Fri, Jan 12, 2018 at 6:51 AM, Yann Ylavic  > wrote:
>> A bit orthogonal, I'd also like to sync 2.4.x "event" with trunk's
>> w.r.t. cosmetic changes before (and to help) further backport
>> proposals.
>> 
>> That's possibly something that'll help *us* for later backports, but
>> not necessarily distros with (security-)fixes only policy.
>> Is that something we should more care about? I suppose distro
>> maintainers do care...
>> 
>> For instance, the three attached patches are how I would stage latest
>> "event" changes in 2.4.x:
>> - patch 1: align with trunk what can/needs to be (cosmetics);
>> - patch 2: optimizations and correctness which don't seem to have
>> bitten us so far (not a proven fix someow);
>> - patch 3: a wakeup fix (corner case) that applies almost cleanly
>> thanks to 1/ and 2/.
>> 
>> Would this work or should I go with 3/ directly and resolve backport
>> conflicts there?
>> Or maybe go with 3/ then 2/ then 1/, for the same result but at least
>> distros would care of the first step only (for this time...)?
> 
> Looks reasonable to me, better to rip the band-aid off then pay the
> price/risk every time something needs to be backported.

+1

BTW, there is no need for some of this stuff to be part of the public
API.

Re: can we haz backports?

[Jim Jagielski]

Vetos must be justified... for solid, technical reasons.

One cannot just cast a -1 vote because one doesn't like
something. Way too often I see being blocking stuff
instead of working to *unblock* stuff.


> On Jan 12, 2018, at 6:32 AM, Steffen  wrote:
> 
> Now mod_md contains features which are not supported anymore ! 
> 
> For SSL only config mod_md is not usable anymore, see 
> https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188
>  
> 
>  
> 
> Propose to change mod_md regarding above, now I vote -1. 
> 
> On windows I advise LE-Win-Simple with its selfhosting option when you have 
> SSL only. 
> 
> 
> 
> Op 12 jan. 2018 om 12:14 heeft Stefan Eissing  > het volgende geschreven:
> 
>> Team,
>> 
>> the frequency that people keep on asking me when ACME 
>> support in Apache will be released is going up. For 
>> this to happen, two backports need 1(!) more vote:
>> 
>> 1. core/mod_ssl: Add new flag int to module struct.
>> existing votes: icing, ylavic
>> 2. mod_md: backport of ACME (Let's Encrypt) support. 
>> existing votes: icing, jim
>> 
>> Is anyone planning to review this in the next days? Maybe,
>> since everyone has limited time, coordinating this might
>> be helpful?
>> 
>> Hoping to hear back from you.
>> 
>> Cheers,
>> 
>> Stefan
>> 
>> 

Re: Align worker's worker's fdqueue with event's?

[Luca Toscano]

2018-01-12 13:34 GMT+01:00 Ruediger Pluem :

>
>
> On 01/12/2018 01:32 PM, Eric Covener wrote:
> > On Fri, Jan 12, 2018 at 6:51 AM, Yann Ylavic 
> wrote:
> >> A bit orthogonal, I'd also like to sync 2.4.x "event" with trunk's
> >> w.r.t. cosmetic changes before (and to help) further backport
> >> proposals.
> >>
> >> That's possibly something that'll help *us* for later backports, but
> >> not necessarily distros with (security-)fixes only policy.
> >> Is that something we should more care about? I suppose distro
> >> maintainers do care...
> >>
> >> For instance, the three attached patches are how I would stage latest
> >> "event" changes in 2.4.x:
> >> - patch 1: align with trunk what can/needs to be (cosmetics);
> >> - patch 2: optimizations and correctness which don't seem to have
> >> bitten us so far (not a proven fix someow);
> >> - patch 3: a wakeup fix (corner case) that applies almost cleanly
> >> thanks to 1/ and 2/.
> >>
> >> Would this work or should I go with 3/ directly and resolve backport
> >> conflicts there?
> >> Or maybe go with 3/ then 2/ then 1/, for the same result but at least
> >> distros would care of the first step only (for this time...)?
> >
> > Looks reasonable to me, better to rip the band-aid off then pay the
> > price/risk every time something needs to be backported.
> >
>
> +1
>
>
+1!

Re: remoteip module - extended support in 2.4 branch

[William A Rowe Jr]

You are confusing functionality. the remoteip evaluation happens after
the proxy protocol endpoints are identified. PROXY is a
connection-oriented change of the apparent request origin. The
remoteip behavior is a request-oriented change of the apparent origin,
and it can vary from request to request on the same connection.

Right now there is a proxy-specific blacklist to not expect nor
process PROXY headers from specific client IPs/subnets, this directive
has no effect on remoteip's trust list.

Next, we anticipate a proxy-specific whitelist to enable processing of
PROXY headers only from specific client IPs/subnets. It would still be
followed by the blacklist exclusions.

The net result is a binary decision of whether PROXY header is or is
not expected, and therefore required. There was once an 'optional'
behavior, but we noted the ambiguity would lead to security concerns.

After the PROXY handling is complete, remoteip can further intervene,
request-by-request.


On Thu, Jan 11, 2018 at 10:56 PM, Marcin Giedz  wrote:
> Thx William, good to hear there are no API changes and module from trunk
> should fit to 2.4 . The most important feature for me is actually one
> disabling PROXY mode for particular IPs - something I can not achieve with
> proxy_protocol external module
>
> M.
>
> 
> Od: "William A Rowe Jr" 
> Do: "dev" 
> Wysłane: piątek, 12 styczeń 2018 0:11:19
> Temat: Re: remoteip module - extended support in 2.4 branch
>
> Marcin,
>
> There are no required API changes; you should be able to drop in the trunk
> version of mod_remoteip.c and it should just compiler. Or you can compile
> the trunk module with apxs -c
>
> There is one agreed/anticipated change, to enable PROXY protocol on a remote
> client IP basis (e.g. enable for proxy machines' IPs but not for other local
> traffic.) That should be the primary delta between what is in trunk and what
> will ship in 2.4.
>
> Other questions such as splitting this off into a mod_proxy_protocol module
> are up in the air, and shouldn't affect the module behavior.
>
>
> On Jan 11, 2018 10:33 AM, "Marcin Giedz"  wrote:
>
> is there any timeline for this ? or I should build httpd myself from trunk ?
>
> 
> Od: "Eric Covener" 
> Do: "dev" 
> Wysłane: czwartek, 11 styczeń 2018 15:20:56
> Temat: Re: remoteip module - extended support in 2.4 branch
>
> On Thu, Jan 11, 2018 at 9:10 AM, Marcin Giedz  wrote:
>> Hi there,sent the same question to users list but seems like dev is rather
>> better place.
>>
>> In trunk version remoteip has been extended with some PROXY protocol
>> support. Are there any chances these changes will be backported to 2.4
>> branch ?
>
> There are chances, but there is some disagreement over how/where (part
> of remoteip or not is one dimension of it)
>
>
>

Re: remoteip module - extended support in 2.4 branch

[Marcin Giedz]

Perhaps you're right but it really does what I want - at least on test . I did 
svn from trunk, complied this module and installed on latest 2.4.29. In my env 
we've got haproxy (pass-through) on the front side and then apaches terminating 
SSL. There is a need to record real IP address when client requests site. I was 
able to read this IP using mod_proxy_protocol but there was one downside of it 
- Proxy mode was enabled for entire virtual host without blacklisting e.g. 
local flow. Just a few days ago I was reading apache docs and accidentally 
switch to 2.5 page and found these two options: 

RemoteIPProxyProtocol On 
RemoteIPProxyProtocolExceptions 127.0.0.1 192.168.93.0/24 

there was one mark saying - these are available in 2.4 starting from 2.4.28 
(afair) but... ended up with what you suggested and seems like got what I 
wanted. Does this make more sense ? 

Thx 
Marcin 


Od: "William A Rowe Jr"  
Do: "dev"  
Wysłane: piątek, 12 styczeń 2018 19:11:42 
Temat: Re: remoteip module - extended support in 2.4 branch 

You are confusing functionality. the remoteip evaluation happens after 
the proxy protocol endpoints are identified. PROXY is a 
connection-oriented change of the apparent request origin. The 
remoteip behavior is a request-oriented change of the apparent origin, 
and it can vary from request to request on the same connection. 

Right now there is a proxy-specific blacklist to not expect nor 
process PROXY headers from specific client IPs/subnets, this directive 
has no effect on remoteip's trust list. 

Next, we anticipate a proxy-specific whitelist to enable processing of 
PROXY headers only from specific client IPs/subnets. It would still be 
followed by the blacklist exclusions. 

The net result is a binary decision of whether PROXY header is or is 
not expected, and therefore required. There was once an 'optional' 
behavior, but we noted the ambiguity would lead to security concerns. 

After the PROXY handling is complete, remoteip can further intervene, 
request-by-request. 


On Thu, Jan 11, 2018 at 10:56 PM, Marcin Giedz  wrote: 
> Thx William, good to hear there are no API changes and module from trunk 
> should fit to 2.4 . The most important feature for me is actually one 
> disabling PROXY mode for particular IPs - something I can not achieve with 
> proxy_protocol external module 
> 
> M. 
> 
>  
> Od: "William A Rowe Jr"  
> Do: "dev"  
> Wysłane: piątek, 12 styczeń 2018 0:11:19 
> Temat: Re: remoteip module - extended support in 2.4 branch 
> 
> Marcin, 
> 
> There are no required API changes; you should be able to drop in the trunk 
> version of mod_remoteip.c and it should just compiler. Or you can compile 
> the trunk module with apxs -c 
> 
> There is one agreed/anticipated change, to enable PROXY protocol on a remote 
> client IP basis (e.g. enable for proxy machines' IPs but not for other local 
> traffic.) That should be the primary delta between what is in trunk and what 
> will ship in 2.4. 
> 
> Other questions such as splitting this off into a mod_proxy_protocol module 
> are up in the air, and shouldn't affect the module behavior. 
> 
> 
> On Jan 11, 2018 10:33 AM, "Marcin Giedz"  wrote: 
> 
> is there any timeline for this ? or I should build httpd myself from trunk ? 
> 
>  
> Od: "Eric Covener"  
> Do: "dev"  
> Wysłane: czwartek, 11 styczeń 2018 15:20:56 
> Temat: Re: remoteip module - extended support in 2.4 branch 
> 
> On Thu, Jan 11, 2018 at 9:10 AM, Marcin Giedz  wrote: 
>> Hi there,sent the same question to users list but seems like dev is rather 
>> better place. 
>> 
>> In trunk version remoteip has been extended with some PROXY protocol 
>> support. Are there any chances these changes will be backported to 2.4 
>> branch ? 
> 
> There are chances, but there is some disagreement over how/where (part 
> of remoteip or not is one dimension of it) 
> 
> 
>