Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Twenty years in core, with one bug to fix.
And you couldn’t even manage without three different botched releases.

Please, for the love of its users, stop fixing it.

Joe Schaefer, Ph.D.

Orion - The Enterprise Jamstack Wiki 

954.253.3732 




On Wed, Feb 14, 2024 at 11:12 PM Joe Schaefer  wrote:

> Look Eric,
>
> I gave you beta males an entire year to find an excuse for completely
> boning the modperl user community for no good reason, other than your
> precious egos were harmed while going though the motions for the past ten
> years with this project.
>
> So far, the only thing to come of putting apreq inside httpd is that third
> party quality control teams put some elbow grease into fuzzing its various
> parsers and found a sore spot that you bland engineers felt put upon to
> fix.  And so you botched that patch too, largely out of spite for the
> makework.
>
> There’s a reason the Dean Gaudet‘s of the development sector lost interest
> in hanging out with the weenie tot brigade people like Eric represent.
>
> It’s why I want out now too.
>
>
> Joe Schaefer, Ph.D.
> 
> Orion - The Enterprise Jamstack Wiki
> 
> 
> 954.253.3732 
>
>
>
>
> On Wed, Feb 14, 2024 at 10:33 PM Joe Schaefer  wrote:
>
>> Bite me Eric.
>>
>> Next?
>>
>>
>> Joe Schaefer, Ph.D.
>> 
>> Orion - The Enterprise Jamstack Wiki
>> 
>> 
>> 954.253.3732 
>>
>>
>>
>>
>> On Wed, Feb 14, 2024 at 10:25 PM Eric Covener  wrote:
>>
>>> On Wed, Feb 14, 2024 at 1:45 PM Joe Schaefer  wrote:
>>> >
>>> > Assuming Google hasn't found any more fuzzing vulnerabilities with
>>> apreq, we should call the subproject done after releasing it, rolling any
>>> new efforts into httpd's internal copy of the codebase for the next major
>>> release of httpd.
>>> >
>>> > Sound like a plan?  I can get the ball rolling on the RM process
>>> assuming I still have working login (or can reacquire it via pw reset.
>>>
>>> I think another apreq release makes sense.
>>>
>>> But from the few relevant threads over the years (many on private
>>> lists), there seems to be little maintainer support for apreq much
>>> less apreq embedded in httpd. If there ever were a release branched
>>> from trunk, I don't think it's likely the embedded apreq would
>>> survive.  I think it's a big consideration for what's done with the
>>> standalone tree.
>>>
>>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Look Eric,

I gave you beta males an entire year to find an excuse for completely
boning the modperl user community for no good reason, other than your
precious egos were harmed while going though the motions for the past ten
years with this project.

So far, the only thing to come of putting apreq inside httpd is that third
party quality control teams put some elbow grease into fuzzing its various
parsers and found a sore spot that you bland engineers felt put upon to
fix.  And so you botched that patch too, largely out of spite for the
makework.

There’s a reason the Dean Gaudet‘s of the development sector lost interest
in hanging out with the weenie tot brigade people like Eric represent.

It’s why I want out now too.

Joe Schaefer, Ph.D.

Orion - The Enterprise Jamstack Wiki 

954.253.3732 




On Wed, Feb 14, 2024 at 10:33 PM Joe Schaefer  wrote:

> Bite me Eric.
>
> Next?
>
>
> Joe Schaefer, Ph.D.
> 
> Orion - The Enterprise Jamstack Wiki
> 
> 
> 954.253.3732 
>
>
>
>
> On Wed, Feb 14, 2024 at 10:25 PM Eric Covener  wrote:
>
>> On Wed, Feb 14, 2024 at 1:45 PM Joe Schaefer  wrote:
>> >
>> > Assuming Google hasn't found any more fuzzing vulnerabilities with
>> apreq, we should call the subproject done after releasing it, rolling any
>> new efforts into httpd's internal copy of the codebase for the next major
>> release of httpd.
>> >
>> > Sound like a plan?  I can get the ball rolling on the RM process
>> assuming I still have working login (or can reacquire it via pw reset.
>>
>> I think another apreq release makes sense.
>>
>> But from the few relevant threads over the years (many on private
>> lists), there seems to be little maintainer support for apreq much
>> less apreq embedded in httpd. If there ever were a release branched
>> from trunk, I don't think it's likely the embedded apreq would
>> survive.  I think it's a big consideration for what's done with the
>> standalone tree.
>>
>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Bite me Eric.

Next?

Joe Schaefer, Ph.D.

Orion - The Enterprise Jamstack Wiki 

954.253.3732 




On Wed, Feb 14, 2024 at 10:25 PM Eric Covener  wrote:

> On Wed, Feb 14, 2024 at 1:45 PM Joe Schaefer  wrote:
> >
> > Assuming Google hasn't found any more fuzzing vulnerabilities with
> apreq, we should call the subproject done after releasing it, rolling any
> new efforts into httpd's internal copy of the codebase for the next major
> release of httpd.
> >
> > Sound like a plan?  I can get the ball rolling on the RM process
> assuming I still have working login (or can reacquire it via pw reset.
>
> I think another apreq release makes sense.
>
> But from the few relevant threads over the years (many on private
> lists), there seems to be little maintainer support for apreq much
> less apreq embedded in httpd. If there ever were a release branched
> from trunk, I don't think it's likely the embedded apreq would
> survive.  I think it's a big consideration for what's done with the
> standalone tree.
>

Re: release apreq 2.18 and mothball the project

[Eric Covener]

On Wed, Feb 14, 2024 at 1:45 PM Joe Schaefer  wrote:
>
> Assuming Google hasn't found any more fuzzing vulnerabilities with apreq, we 
> should call the subproject done after releasing it, rolling any new efforts 
> into httpd's internal copy of the codebase for the next major release of 
> httpd.
>
> Sound like a plan?  I can get the ball rolling on the RM process assuming I 
> still have working login (or can reacquire it via pw reset.

I think another apreq release makes sense.

But from the few relevant threads over the years (many on private
lists), there seems to be little maintainer support for apreq much
less apreq embedded in httpd. If there ever were a release branched
from trunk, I don't think it's likely the embedded apreq would
survive.  I think it's a big consideration for what's done with the
standalone tree.

Re: reset in proxy_balancer_method

[Ruediger Pluem]

On 2/14/24 3:45 PM, jean-frederic clere wrote:
> On 2/14/24 08:19, Ruediger Pluem wrote:
>>
>>
>> On 2/9/24 11:59 AM, jean-frederic clere wrote:
>>> Hi,
>>>
>>> I have noted to the reset() clean up too much in the balancers:
>>> mod_lbmethod_bybusyness.c for example does:
>>> +++
>>>  for (i = 0; i < balancer->workers->nelts; i++, worker++) {
>>>  (*worker)->s->lbstatus = 0;
>>>  ap_proxy_set_busy_count(*worker, 0); /* BAD */
>>>  }
>>> +++
>>> In fact reset() is called by ap_proxy_initialize_balancer() when a child 
>>> process is created... Resetting the counters messes up
>>> the logic.
>>>
>>> Does it make sense to stop calling reset() from 
>>> ap_proxy_initialize_balancer() or is it better to fix all reset()?
>>
>> I am not sure what the original idea / intention of reset was. Until this is 
>> clarified I would not remove the call to reset in
>> ap_proxy_initialize_balancer(). In ap_proxy_sync_balancer the call to it is 
>> guarded by a check for the need_reset flag. Maybe this
>> gives a hint.

Rethinking this. I guess we lack a clear API definition of the reset method of 
a balancer provider and it does not really seem
sensible to reset the stats in case a new child is created. Hence I guess the 
regression risk is rather low when just removing
this call to reset.

> 
> The need_reset is set when a worker is enabled or when the load balancing 
> method is changed.

Isn't that a similar situation to when a worker is added (in respect to the 
point below)?

> 
>>
>>>
>>>
>>> There is another thing adding a new worker via /balancer-manager/ probably 
>>> requires some kind of reset() otherwise all the load
>>> moves to the new worker which is not the best May be calling age() or 
>>> triggering calls to age() can help.
>>
>> Doesn't ap_proxy_sync_balancer take care of this which is called before 
>> processing a request?
>>

Regards

Rüdiger

release apreq 2.18 and mothball the project

[Joe Schaefer]

Assuming Google hasn't found any more fuzzing vulnerabilities with apreq,
we should call the subproject done after releasing it, rolling any new
efforts into httpd's internal copy of the codebase for the next major
release of httpd.

Sound like a plan?  I can get the ball rolling on the RM process assuming I
still have working login (or can reacquire it via pw reset.

-- 
Joe Schaefer, Ph.D.

Orion - The Enterprise Jamstack Wiki 

954.253.3732 

Re: reset in proxy_balancer_method

[jean-frederic clere]

On 2/14/24 08:19, Ruediger Pluem wrote:



On 2/9/24 11:59 AM, jean-frederic clere wrote:

Hi,

I have noted to the reset() clean up too much in the balancers:
mod_lbmethod_bybusyness.c for example does:
+++
     for (i = 0; i < balancer->workers->nelts; i++, worker++) {
     (*worker)->s->lbstatus = 0;
     ap_proxy_set_busy_count(*worker, 0); /* BAD */
     }
+++
In fact reset() is called by ap_proxy_initialize_balancer() when a child 
process is created... Resetting the counters messes up
the logic.

Does it make sense to stop calling reset() from ap_proxy_initialize_balancer() 
or is it better to fix all reset()?


I am not sure what the original idea / intention of reset was. Until this is 
clarified I would not remove the call to reset in
ap_proxy_initialize_balancer(). In ap_proxy_sync_balancer the call to it is 
guarded by a check for the need_reset flag. Maybe this
gives a hint.


The need_reset is set when a worker is enabled or when the load 
balancing method is changed.







There is another thing adding a new worker via /balancer-manager/ probably 
requires some kind of reset() otherwise all the load
moves to the new worker which is not the best May be calling age() or 
triggering calls to age() can help.


Doesn't ap_proxy_sync_balancer take care of this which is called before 
processing a request?

Regards

Rüdiger



--
Cheers

Jean-Frederic

Re: svn commit: r1915782 - in /httpd/httpd/branches/2.4.x: ./ build/PrintPath build/find_apr.m4 build/find_apu.m4 changes-entries/mod_slotmem_shm.txt modules/slotmem/mod_slotmem_shm.c

[jean-frederic clere]

On 2/14/24 12:18, jfcl...@apache.org wrote:

Removed:
 httpd/httpd/branches/2.4.x/build/PrintPath
 httpd/httpd/branches/2.4.x/build/find_apr.m4
 httpd/httpd/branches/2.4.x/build/find_apu.m4


Oops I have undone that, sorry.
--
Cheers

Jean-Frederic

Re: using changes-entries or write in CHANGES directly

[Joe Orton]

On Wed, Feb 14, 2024 at 11:28:15AM +0100, jean-frederic clere wrote:
> So for 2.4.x on my accepted back port I have don't need changes-entries and
> I have to process CHANGES by hands as I missed creating a changes-entries
> file in trunk.

If you file a Github PR for the backport you can still add a 
changes-entries/ file there (same if you create a patch and upload it 
somewhere). It makes the change easy to merge independent of other 
commits, avoiding conflicts adding directly to CHANGES. Works really 
well (thanks Rűdiger!)

Regards, Joe

Re: using changes-entries or write in CHANGES directly

[jean-frederic clere]

On 2/14/24 11:06, Ruediger Pluem wrote:



On 2/14/24 10:53 AM, jean-frederic clere wrote:

Hi,

Are there any rules to use changes-entries or write directly in CHANGES?




IMHO change-entries is preferred. See 
http://svn.apache.org/viewvc/httpd/httpd/trunk/README.CHANGES?view=markup

I just noticed that we probably need a better cleanup mechanism for 
change-entries in trunk as I guess that
we do not want to add backported changes to the trunk CHANGES file. But this 
problem has been there in the past
as well that direct edits to CHANGES in trunk were not properly reverted once 
this change was backported.
But the usage of change-entries should ease this process.


OK thanks...

So for 2.4.x on my accepted back port I have don't need changes-entries 
and I have to process CHANGES by hands as I missed creating a 
changes-entries file in trunk.





Regards

Rüdiger


--
Cheers

Jean-Frederic

Re: using changes-entries or write in CHANGES directly

[Ruediger Pluem]

On 2/14/24 10:53 AM, jean-frederic clere wrote:
> Hi,
> 
> Are there any rules to use changes-entries or write directly in CHANGES?
> 


IMHO change-entries is preferred. See 
http://svn.apache.org/viewvc/httpd/httpd/trunk/README.CHANGES?view=markup

I just noticed that we probably need a better cleanup mechanism for 
change-entries in trunk as I guess that
we do not want to add backported changes to the trunk CHANGES file. But this 
problem has been there in the past
as well that direct edits to CHANGES in trunk were not properly reverted once 
this change was backported.
But the usage of change-entries should ease this process.


Regards

Rüdiger

Re: using changes-entries or write in CHANGES directly

[Stefan Eissing via dev]

> Am 14.02.2024 um 10:53 schrieb jean-frederic clere :
> 
> Hi,
> 
> Are there any rules to use changes-entries or write directly in CHANGES?

Files in changes-entries make it easier to backport, as they will be no 
conflicts.

> 
> -- 
> Cheers
> 
> Jean-Frederic

using changes-entries or write in CHANGES directly

[jean-frederic clere]

Hi,

Are there any rules to use changes-entries or write directly in CHANGES?

--
Cheers

Jean-Frederic