Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

The mediocre talent pool in this community doesn’t mind the code
duplication of having many different form data parsers inside a common code
base because, really, collaboration and common cause is not your thing.

So live it up with the user base while they ponder your architectural
rationales like this guy does:

https://stackoverflow.com/questions/60281807/get-post-request-body-and-decode-using-mod-lua-apache-http-2-4



Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 




On Thu, Feb 15, 2024 at 8:47 PM Joe Schaefer  wrote:

> Stupid shit like this is everyone's problem:
>
> https://www.tenable.com/plugins/nessus/161454
>
> Hating me for solving it cleanly is par for the course for the current
> httpd committer community.
>
> On Thu, Feb 15, 2024 at 8:41 PM Joe Schaefer  wrote:
>
>> Back in the day, httpd was a celebrated integration point for dozens of
>> apache projects. Literally the flagship of the organization.
>>
>> It's also why people were judicious about what to include in core, versus
>> codebases remaining elsewhere in the org as third party modules.
>>
>> Of course at this point, there's no good reason to hook a dynamic
>> language into core in a non-thread-safe way.  Yet mod_lua exists.
>> If there's no good reason to hook a thread-safe httpd-specific HTML form
>> parser technology into the mix, what is mod_dav doing in here?
>>
>> The obvious answer is because peevishness rules the day at Apache.  Very
>> Important People's pet projects have staying power, not because users
>> demand it, but because the personalities behind them would give you serious
>> shit for discarding the module on a whim.
>>
>> All I ask for is to be able to bow out and never return to this group
>> again.
>>
>>
>>
>> On Thu, Feb 15, 2024 at 8:20 PM Joe Schaefer  wrote:
>>
>>> The proof is in the pudding, as it were.
>>>
>>> There's prima facia evidence in this very thread that he lied about ever
>>> running the test suite for apreq, because Joe wouldn't have had to patch it
>>> for him 8 months later had he ever bothered in the first place.
>>>
>>> But when everyone around you is no better than that, there's
>>> participation trophies for all of you!
>>>
>>> On Thu, Feb 15, 2024 at 8:17 PM Eric Covener  wrote:
>>>
>>>> > And because you are such a prima donna Yann
>>>>
>>>> Yann is an amazing programmer and super easy to work with. Maybe it's
>>>> hard to tell from the backseat.
>>>>
>>>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Stupid shit like this is everyone's problem:

https://www.tenable.com/plugins/nessus/161454

Hating me for solving it cleanly is par for the course for the current
httpd committer community.

On Thu, Feb 15, 2024 at 8:41 PM Joe Schaefer  wrote:

> Back in the day, httpd was a celebrated integration point for dozens of
> apache projects. Literally the flagship of the organization.
>
> It's also why people were judicious about what to include in core, versus
> codebases remaining elsewhere in the org as third party modules.
>
> Of course at this point, there's no good reason to hook a dynamic language
> into core in a non-thread-safe way.  Yet mod_lua exists.
> If there's no good reason to hook a thread-safe httpd-specific HTML form
> parser technology into the mix, what is mod_dav doing in here?
>
> The obvious answer is because peevishness rules the day at Apache.  Very
> Important People's pet projects have staying power, not because users
> demand it, but because the personalities behind them would give you serious
> shit for discarding the module on a whim.
>
> All I ask for is to be able to bow out and never return to this group
> again.
>
>
>
> On Thu, Feb 15, 2024 at 8:20 PM Joe Schaefer  wrote:
>
>> The proof is in the pudding, as it were.
>>
>> There's prima facia evidence in this very thread that he lied about ever
>> running the test suite for apreq, because Joe wouldn't have had to patch it
>> for him 8 months later had he ever bothered in the first place.
>>
>> But when everyone around you is no better than that, there's
>> participation trophies for all of you!
>>
>> On Thu, Feb 15, 2024 at 8:17 PM Eric Covener  wrote:
>>
>>> > And because you are such a prima donna Yann
>>>
>>> Yann is an amazing programmer and super easy to work with. Maybe it's
>>> hard to tell from the backseat.
>>>
>>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Back in the day, httpd was a celebrated integration point for dozens of
apache projects. Literally the flagship of the organization.

It's also why people were judicious about what to include in core, versus
codebases remaining elsewhere in the org as third party modules.

Of course at this point, there's no good reason to hook a dynamic language
into core in a non-thread-safe way.  Yet mod_lua exists.
If there's no good reason to hook a thread-safe httpd-specific HTML form
parser technology into the mix, what is mod_dav doing in here?

The obvious answer is because peevishness rules the day at Apache.  Very
Important People's pet projects have staying power, not because users
demand it, but because the personalities behind them would give you serious
shit for discarding the module on a whim.

All I ask for is to be able to bow out and never return to this group again.



On Thu, Feb 15, 2024 at 8:20 PM Joe Schaefer  wrote:

> The proof is in the pudding, as it were.
>
> There's prima facia evidence in this very thread that he lied about ever
> running the test suite for apreq, because Joe wouldn't have had to patch it
> for him 8 months later had he ever bothered in the first place.
>
> But when everyone around you is no better than that, there's participation
> trophies for all of you!
>
> On Thu, Feb 15, 2024 at 8:17 PM Eric Covener  wrote:
>
>> > And because you are such a prima donna Yann
>>
>> Yann is an amazing programmer and super easy to work with. Maybe it's
>> hard to tell from the backseat.
>>
>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

The proof is in the pudding, as it were.

There's prima facia evidence in this very thread that he lied about ever
running the test suite for apreq, because Joe wouldn't have had to patch it
for him 8 months later had he ever bothered in the first place.

But when everyone around you is no better than that, there's participation
trophies for all of you!

On Thu, Feb 15, 2024 at 8:17 PM Eric Covener  wrote:

> > And because you are such a prima donna Yann
>
> Yann is an amazing programmer and super easy to work with. Maybe it's hard
> to tell from the backseat.
>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

 The nightmare scenario is when you try to support HTTP/3 when you can’t
even support an HTML form parser.

Have an appropriate amount of fun. Popcorn is popping.

Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 




On Thu, Feb 15, 2024 at 7:36 PM Joe Schaefer  wrote:

> The reason the QA around httpd is so lousy lately is because none of you
> actually dogfood the software professionally, because no Fortune 500
> employer would be caught dead running httpd over nginx in the cloud.
>
> That historically lackadaisical approach to CI has no business persisting
> now that you are on GitHub.
>
> And yet it persists.
>
> It also is why you guinea pig your user base instead of respecting them,
> because you aren’t a part of that community any more.
>
> And it shows with each new dud delivered to the apreq user base over the
> past decade.
>
> So let’s end this fiasco ASAP.
>
> Joe Schaefer, Ph.D.
> <https://sunstarsys.com/orion/features>
> Orion - The Enterprise Jamstack Wiki
> <https://sunstarsys.com/orion/features>
> 
> 954.253.3732 
>
>
>
>
> On Thu, Feb 15, 2024 at 7:08 PM Joe Schaefer  wrote:
>
>> Keep your tone policing off list wise guy. If you have something of
>> substance to offer to your colleagues other than defensive posturing, let’s
>> have it.
>>
>> Like all these vacuous bug reports missing from the issue tracker about
>> apreq, that you rumor mongers like to scare people with.
>>
>> Joe Schaefer, Ph.D.
>> <https://sunstarsys.com/orion/features>
>> Orion - The Enterprise Jamstack Wiki
>> <https://sunstarsys.com/orion/features>
>> 
>> 954.253.3732 
>>
>>
>>
>>
>> On Thu, Feb 15, 2024 at 7:03 PM Frank Gingras  wrote:
>>
>>>
>>>
>>> On Thu, Feb 15, 2024 at 5:47 PM Joe Schaefer  wrote:
>>>
>>>> Nobody gives a flying f what you released from trunk. I personally will
>>>> be dead and buried before you release httpd 3.0.  So like you I don’t give
>>>> a damned what you do with it.
>>>>
>>>> I just want the warfare against existing libapreq2 users to cease and
>>>> desist.
>>>>
>>>> If there are known vulnerabilities in the existing codebase, you have a
>>>> professional obligation to report them to the security team, who have
>>>> assured me they will send them my way for proper handling by a competent
>>>> engineer.
>>>>
>>>> None have been forthcoming, so that’s reason to release 2.18 as-is and
>>>> mothball the subproject so we need not deal with each other again over it.
>>>>
>>>> Thanks
>>>>
>>>> Joe Schaefer, Ph.D.
>>>> <https://sunstarsys.com/orion/features>
>>>> Orion - The Enterprise Jamstack Wiki
>>>> <https://sunstarsys.com/orion/features>
>>>> 
>>>> 954.253.3732 
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Feb 15, 2024 at 5:17 PM Eric Covener  wrote:
>>>>
>>>>> On Wed, Feb 14, 2024 at 11:57 PM Joe Schaefer 
>>>>> wrote:
>>>>>
>>>>>> Twenty years in core, with one bug to fix.
>>>>>> And you couldn’t even manage without three different botched releases.
>>>>>>
>>>>>
>>>>> I think you are mixing up apreq and httpd releases here.
>>>>> AIUI the apreq stuff in the core of httpd-trunk has only ever been in
>>>>> one alpha release, and predates the regression.
>>>>>
>>>>> I'll keep any advice about an apreq release to myself, good luck and
>>>>> please be mindful of the CoC
>>>>> https://www.apache.org/foundation/policies/conduct
>>>>>
>>>>>
>>> Respectfully, the tone of that response was unwarranted. There are
>>> better ways to express your opinion that don't require attacks, and
>>> cynicism.
>>>
>>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

The reason the QA around httpd is so lousy lately is because none of you
actually dogfood the software professionally, because no Fortune 500
employer would be caught dead running httpd over nginx in the cloud.

That historically lackadaisical approach to CI has no business persisting
now that you are on GitHub.

And yet it persists.

It also is why you guinea pig your user base instead of respecting them,
because you aren’t a part of that community any more.

And it shows with each new dud delivered to the apreq user base over the
past decade.

So let’s end this fiasco ASAP.

Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 




On Thu, Feb 15, 2024 at 7:08 PM Joe Schaefer  wrote:

> Keep your tone policing off list wise guy. If you have something of
> substance to offer to your colleagues other than defensive posturing, let’s
> have it.
>
> Like all these vacuous bug reports missing from the issue tracker about
> apreq, that you rumor mongers like to scare people with.
>
> Joe Schaefer, Ph.D.
> <https://sunstarsys.com/orion/features>
> Orion - The Enterprise Jamstack Wiki
> <https://sunstarsys.com/orion/features>
> 
> 954.253.3732 
>
>
>
>
> On Thu, Feb 15, 2024 at 7:03 PM Frank Gingras  wrote:
>
>>
>>
>> On Thu, Feb 15, 2024 at 5:47 PM Joe Schaefer  wrote:
>>
>>> Nobody gives a flying f what you released from trunk. I personally will
>>> be dead and buried before you release httpd 3.0.  So like you I don’t give
>>> a damned what you do with it.
>>>
>>> I just want the warfare against existing libapreq2 users to cease and
>>> desist.
>>>
>>> If there are known vulnerabilities in the existing codebase, you have a
>>> professional obligation to report them to the security team, who have
>>> assured me they will send them my way for proper handling by a competent
>>> engineer.
>>>
>>> None have been forthcoming, so that’s reason to release 2.18 as-is and
>>> mothball the subproject so we need not deal with each other again over it.
>>>
>>> Thanks
>>>
>>> Joe Schaefer, Ph.D.
>>> <https://sunstarsys.com/orion/features>
>>> Orion - The Enterprise Jamstack Wiki
>>> <https://sunstarsys.com/orion/features>
>>> 
>>> 954.253.3732 
>>>
>>>
>>>
>>>
>>> On Thu, Feb 15, 2024 at 5:17 PM Eric Covener  wrote:
>>>
>>>> On Wed, Feb 14, 2024 at 11:57 PM Joe Schaefer 
>>>> wrote:
>>>>
>>>>> Twenty years in core, with one bug to fix.
>>>>> And you couldn’t even manage without three different botched releases.
>>>>>
>>>>
>>>> I think you are mixing up apreq and httpd releases here.
>>>> AIUI the apreq stuff in the core of httpd-trunk has only ever been in
>>>> one alpha release, and predates the regression.
>>>>
>>>> I'll keep any advice about an apreq release to myself, good luck and
>>>> please be mindful of the CoC
>>>> https://www.apache.org/foundation/policies/conduct
>>>>
>>>>
>> Respectfully, the tone of that response was unwarranted. There are better
>> ways to express your opinion that don't require attacks, and cynicism.
>>
>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Keep your tone policing off list wise guy. If you have something of
substance to offer to your colleagues other than defensive posturing, let’s
have it.

Like all these vacuous bug reports missing from the issue tracker about
apreq, that you rumor mongers like to scare people with.

Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 




On Thu, Feb 15, 2024 at 7:03 PM Frank Gingras  wrote:

>
>
> On Thu, Feb 15, 2024 at 5:47 PM Joe Schaefer  wrote:
>
>> Nobody gives a flying f what you released from trunk. I personally will
>> be dead and buried before you release httpd 3.0.  So like you I don’t give
>> a damned what you do with it.
>>
>> I just want the warfare against existing libapreq2 users to cease and
>> desist.
>>
>> If there are known vulnerabilities in the existing codebase, you have a
>> professional obligation to report them to the security team, who have
>> assured me they will send them my way for proper handling by a competent
>> engineer.
>>
>> None have been forthcoming, so that’s reason to release 2.18 as-is and
>> mothball the subproject so we need not deal with each other again over it.
>>
>> Thanks
>>
>> Joe Schaefer, Ph.D.
>> <https://sunstarsys.com/orion/features>
>> Orion - The Enterprise Jamstack Wiki
>> <https://sunstarsys.com/orion/features>
>> 
>> 954.253.3732 
>>
>>
>>
>>
>> On Thu, Feb 15, 2024 at 5:17 PM Eric Covener  wrote:
>>
>>> On Wed, Feb 14, 2024 at 11:57 PM Joe Schaefer 
>>> wrote:
>>>
>>>> Twenty years in core, with one bug to fix.
>>>> And you couldn’t even manage without three different botched releases.
>>>>
>>>
>>> I think you are mixing up apreq and httpd releases here.
>>> AIUI the apreq stuff in the core of httpd-trunk has only ever been in
>>> one alpha release, and predates the regression.
>>>
>>> I'll keep any advice about an apreq release to myself, good luck and
>>> please be mindful of the CoC
>>> https://www.apache.org/foundation/policies/conduct
>>>
>>>
> Respectfully, the tone of that response was unwarranted. There are better
> ways to express your opinion that don't require attacks, and cynicism.
>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Nobody gives a flying f what you released from trunk. I personally will be
dead and buried before you release httpd 3.0.  So like you I don’t give a
damned what you do with it.

I just want the warfare against existing libapreq2 users to cease and
desist.

If there are known vulnerabilities in the existing codebase, you have a
professional obligation to report them to the security team, who have
assured me they will send them my way for proper handling by a competent
engineer.

None have been forthcoming, so that’s reason to release 2.18 as-is and
mothball the subproject so we need not deal with each other again over it.

Thanks

Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 




On Thu, Feb 15, 2024 at 5:17 PM Eric Covener  wrote:

> On Wed, Feb 14, 2024 at 11:57 PM Joe Schaefer  wrote:
>
>> Twenty years in core, with one bug to fix.
>> And you couldn’t even manage without three different botched releases.
>>
>
> I think you are mixing up apreq and httpd releases here.
> AIUI the apreq stuff in the core of httpd-trunk has only ever been in one
> alpha release, and predates the regression.
>
> I'll keep any advice about an apreq release to myself, good luck and
> please be mindful of the CoC
> https://www.apache.org/foundation/policies/conduct
>
>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Let's be honest for once Yann. You came up with this hairbrained patch over
2 years ago right here:

https://svn.apache.org/viewvc?view=revision=1895107

Yet the first time anyone actually ran the unit tests for apreq was during
the 2.17 release process **8 months later**.  And because you are such a
prima donna Yann, Joe Orton (who I always respect) would rather remove the
test that flagged your patch, just so he could get the damned thing out the
door without dealing with you further.

Instead, he had to deal with me.   Tradeoffs are everywhere in life.


On Thu, Feb 15, 2024 at 2:41 PM Joe Schaefer  wrote:

> You mean the 2.17 release, where Joe Orton actually patched the test suite
> out of your coercion?
>
> Great engineering.
>
> http://svn.apache.org/viewvc?view=revision=1903489
>
>
> Joe Schaefer, Ph.D.
> <https://sunstarsys.com/orion/features>
> Orion - The Enterprise Jamstack Wiki
> <https://sunstarsys.com/orion/features>
> 
> 954.253.3732 
>
>
>
>
> On Thu, Feb 15, 2024 at 2:13 PM Yann Ylavic  wrote:
>
>> On Thu, Feb 15, 2024 at 5:12 AM Joe Schaefer wrote:
>> >
>> > I gave you beta males an entire year
>>
>> His Alpha Most Serene Highness is too kind to us..
>>
>> > to find an excuse for completely boning the modperl user community for
>> no good reason,
>>
>> _You_ did that (boning the modperl user community), by spitting your
>> venom on everyone here (and in all the forums) and nothing else.
>> You, as a member of the httpd team, could have fixed it and
>> started/encouraged a new release with the one-liner fix, yet your
>> first/primary point was to insult others for having touched your
>> (alphally broken) code and introduced a (betally edge) regression,
>> which His Alpha Most Serene Highness' test suite didn't caught btw.
>>
>> > 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.
>>
>> Actually it did find multiple sore spots, otherwise you can imagine
>> that we plebs would never have dared to touch as much of His Alpha
>> Most Serene Highness' code.
>>
>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

You mean the 2.17 release, where Joe Orton actually patched the test suite
out of your coercion?

Great engineering.

http://svn.apache.org/viewvc?view=revision=1903489


Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 




On Thu, Feb 15, 2024 at 2:13 PM Yann Ylavic  wrote:

> On Thu, Feb 15, 2024 at 5:12 AM Joe Schaefer wrote:
> >
> > I gave you beta males an entire year
>
> His Alpha Most Serene Highness is too kind to us..
>
> > to find an excuse for completely boning the modperl user community for
> no good reason,
>
> _You_ did that (boning the modperl user community), by spitting your
> venom on everyone here (and in all the forums) and nothing else.
> You, as a member of the httpd team, could have fixed it and
> started/encouraged a new release with the one-liner fix, yet your
> first/primary point was to insult others for having touched your
> (alphally broken) code and introduced a (betally edge) regression,
> which His Alpha Most Serene Highness' test suite didn't caught btw.
>
> > 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.
>
> Actually it did find multiple sore spots, otherwise you can imagine
> that we plebs would never have dared to touch as much of His Alpha
> Most Serene Highness' code.
>

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.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

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.
> <https://sunstarsys.com/orion/features>
> Orion - The Enterprise Jamstack Wiki
> <https://sunstarsys.com/orion/features>
> 
> 954.253.3732 
>
>
>
>
> On Wed, Feb 14, 2024 at 10:33 PM Joe Schaefer  wrote:
>
>> Bite me Eric.
>>
>> Next?
>>
>>
>> Joe Schaefer, Ph.D.
>> <https://sunstarsys.com/orion/features>
>> Orion - The Enterprise Jamstack Wiki
>> <https://sunstarsys.com/orion/features>
>> 
>> 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.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 




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

> Bite me Eric.
>
> Next?
>
>
> Joe Schaefer, Ph.D.
> <https://sunstarsys.com/orion/features>
> Orion - The Enterprise Jamstack Wiki
> <https://sunstarsys.com/orion/features>
> 
> 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.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

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.
>

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.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 

Re: PR #363

[Joe Schaefer]

With GFM, each line break separates paragraphs.

Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 




On Wed, Jan 24, 2024 at 11:01 AM Yann Ylavic  wrote:

> On Wed, Jan 24, 2024 at 4:56 PM Mads Toftum  wrote:
> >
> > On Wed, Jan 24, 2024 at 10:06:43AM -0500, rbo...@rcbowen.com wrote:
> > > I've been poking at some of our open PRs looking for docs-only changes
> > > that we can possibly clean up.
> > >
> > > PR #363 - https://github.com/apache/httpd/pull/363 - converts README
> > > from plaintext to markdown, and makes no other changes. This makes it
> > > prettier on GitHub.
> > >
> > > I almost just CTR'ed it, but it occurred to me that someone might find
> > > this objectionable, so I thought I'd ask first.
> >
> > I don't have strong opinions on this, but we'll end up with a READNE
> > that's less readable for those not viewing it through github.
>
> Maybe we could keep the line breaks as before for the text to keep it
> as readable as before w/o a markdown viewer?
>
>
> Regards;
> Yann.
>

Re: [VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58

[Joe Schaefer]

Steve Hay was a great resource once upon a time ago, but meh, you can't
draw blood from a stone forever.

On Tue, Oct 17, 2023 at 12:32 PM Steffen  wrote:

> For me still -1.
>
> > Op 17 okt 2023 om 18:18 heeft Stefan Eissing via dev <
> dev@httpd.apache.org> het volgende geschreven:
> >
> > Just got a reply from a contact that build rc3 on win64 and ran it
> successfully. I invited him to participate here, not sure if he will feel
> like it.
> >
> > I count that as a +1 on win64 unless someone objects.
> >
> > Cheers,
> > Stefan
> >
> >
> >> Am 17.10.2023 um 12:05 schrieb Stefan Eissing via dev <
> dev@httpd.apache.org>:
> >>
> >> I am trying to contact another person that builds regularly mod_h2 on
> Windows.
> >>
>  Am 17.10.2023 um 11:30 schrieb Steffen :
> >>>
> >>> Same error on win64.
> >>> Yes the reported mod_http2 errors on 32 and 64.
> >>> Yes, I am not able to tell what is wrong, only I can report the
> errors. I am not a developer, just building and testing.
> >>>
> >>> Regards, Steffen
> >>>
>  Op 17 okt 2023 om 11:08 heeft Stefan Eissing via dev <
> dev@httpd.apache.org> het volgende geschreven:
> 
>  
> 
> > Am 17.10.2023 um 08:41 schrieb Steffen :
> >
> > -1 does not build on windows.
> 
>  If I understood your reports from yesterday correctly, the situation
> is
>  - you can build on win64
>  - you get compiler errors on your win32 build
>  - you are not able to tell us what is wrong
> 
>  Correct?
> 
>  Cheers,
>  Stefan
> 
> >
> > Steffen
> >
> >>> Op 16 okt 2023 om 17:10 heeft Stefan Eissing via dev <
> dev@httpd.apache.org> het volgende geschreven:
> >>
> >> Hi all,
> >>
> >> after fixing my merge mistake in rc2 (sorry!), we go again:
> >>
> >> Please find below the proposed release tarball and signatures:
> >>
> >> https://dist.apache.org/repos/dist/dev/httpd/
> >>
> >> I would like to call a VOTE over the next few days to release
> >> this candidate tarball httpd-2.4.58-rc3 as 2.4.58:
> >> [ ] +1: It's not just good, it's good enough!
> >> [ ] +0: Let's have a talk.
> >> [ ] -1: There's trouble in paradise. Here's what's wrong.
> >>
> >> The computed digests of the tarball up for vote are:
> >> sha256:
> 503a7da4a4a27fd496037998b17078dc9fe004db32c657c96cce8356b8aa2eb6
> *httpd-2.4.58-rc3.tar.gz
> >> sha512:
> 5c11faf0572035ef67b27775d975999411c689cb774553175299a9e99b63d3d7138b0c7f15048ec28038494d8513689f916202c2289d557947d8b190d46ca9f3
> *httpd-2.4.58-rc3.tar.gz
> >>
> >> The SVN candidate source is found at tags/2.4.58-rc3-candidate.
> >>
> >> Cheers,
> >> Stefan
> >
> 
> >>>
> >>
> >
>
>

Re: Please support/enable https by default in the Apache web sever.

[Joe Schaefer]

It is insane to ask this project to cater to the interests of 10 people who
are so PKI illiterate, the PMC needs to put the rest of the user base at
risk just to accommodate them.

Certs require mandatory user serviceable parts.  There is no meaningful way
to  provide a default.

Thanks.

On Sat, Sep 30, 2023 at 10:45 AM General Email <
general.email.12341...@gmail.com> wrote:

>
>
> On Sat, 30 Sep, 2023, 8:00 pm Emmanuel Dreyfus,  wrote:
>
>> On Sat, Sep 30, 2023 at 07:40:34PM +0530, General Email wrote:
>> > By the way, I don't understand how the default certificate can be
>> abused.
>>
>> It is not signed by a trusted CA, hence your browser cannot tell if it
>> is speaking to your legitimate web server, or to some malware lurking
>> in between. Perhaps your web trafic is not worth being evesdropped, but
>> consider a malware could inject an exploit against your browser in your
>> web trafic. The attacker could just be an infected machine on the same
>> LAN.
>>
>> The security level of an untrusted ceritificate is not much better than
>> plain text HTTP.
>>
>
>
> Yes, I understand this.
>
> We will not be using the default untrusted certificate when we go live.
>
> But during development, if 10 people are working on the development of one
> website and each of them has their own apache http installation, then we
> have to generate 10 certificates and do a few changes or more than few
> changes to get https enabled on each of 10 installations.
>
> Having a default certificate (not signed by trusted CA) in official http
> server will make enabling https on each installation much easier and we
> won't have to generate 10 certificates, etc.
>
> Regards,
> GE
>
>

Re: Time for a new libapreq2 release?

[Joe Schaefer]

The readd is an acceptable loss at this point.  Never could avoid Rich’s
spam since he culls from every list.


On Mon, Aug 28, 2023 at 5:51 PM Greg Stein  wrote:

> You "should" have commit access to svn:repos/asf/httpd/ now. We had to
> re-add you to the "committers" list (which also implies receiving future
> emails to that list).
>
>
> On Mon, Aug 28, 2023 at 3:52 PM Joe Schaefer  wrote:
>
>> No objection. Happy to Tag and roll of my account is made available
>> somehow.
>>
>> On Mon, Aug 28, 2023 at 4:50 PM Greg Stein  wrote:
>>
>>> Your LDAP record is still present [1]. You're still on the PMC of httpd
>>> and perl. Commit rights to incubator, sis, subversion. Dunno where httpd
>>> went, but as a PMC member of httpd you should have commit. We can fix that.
>>>
>>> So should we fix this up, so you can walk through a libapreq2 release?
>>>
>>> Cheers,
>>> -g
>>> [1] https://whimsy.apache.org/roster/committer/joes
>>>
>>>
>>> On Mon, Aug 28, 2023 at 8:43 AM Joe Schaefer  wrote:
>>>
>>>> Because my account no longer exists?
>>>>
>>>> On Mon, Aug 28, 2023 at 1:43 AM Greg Stein  wrote:
>>>>
>>>>> you're on the PMC. Why don't you do the tag ?
>>>>>
>>>>> On Sun, Aug 27, 2023 at 4:31 PM Joe Schaefer 
>>>>> wrote:
>>>>>
>>>>>> Seems like it’s been a year since the last release, which means it’s
>>>>>> time for good people to take another try at releasing something
>>>>>> nondefective.
>>>>>>
>>>>>> Here to help with the quality control this time around.
>>>>>> --
>>>>>> Joe Schaefer, Ph.D.
>>>>>> <https://sunstarsys.com/orion/features>
>>>>>> Orion - The Enterprise Jamstack Wiki
>>>>>> <https://sunstarsys.com/orion/features>
>>>>>> 
>>>>>> 954.253.3732 
>>>>>>
>>>>>>
>>>>>> --
>>>> Joe Schaefer, Ph.D.
>>>> <https://sunstarsys.com/orion/features>
>>>> Orion - The Enterprise Jamstack Wiki
>>>> <https://sunstarsys.com/orion/features>
>>>> 
>>>> 954.253.3732 
>>>>
>>>>
>>>> --
>> Joe Schaefer, Ph.D.
>> <https://sunstarsys.com/orion/features>
>> Orion - The Enterprise Jamstack Wiki
>> <https://sunstarsys.com/orion/features>
>> 
>> 954.253.3732 
>>
>>
>> --
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 

Re: Time for a new libapreq2 release?

[Joe Schaefer]

No objection. Happy to Tag and roll of my account is made available somehow.

On Mon, Aug 28, 2023 at 4:50 PM Greg Stein  wrote:

> Your LDAP record is still present [1]. You're still on the PMC of httpd
> and perl. Commit rights to incubator, sis, subversion. Dunno where httpd
> went, but as a PMC member of httpd you should have commit. We can fix that.
>
> So should we fix this up, so you can walk through a libapreq2 release?
>
> Cheers,
> -g
> [1] https://whimsy.apache.org/roster/committer/joes
>
>
> On Mon, Aug 28, 2023 at 8:43 AM Joe Schaefer  wrote:
>
>> Because my account no longer exists?
>>
>> On Mon, Aug 28, 2023 at 1:43 AM Greg Stein  wrote:
>>
>>> you're on the PMC. Why don't you do the tag ?
>>>
>>> On Sun, Aug 27, 2023 at 4:31 PM Joe Schaefer  wrote:
>>>
>>>> Seems like it’s been a year since the last release, which means it’s
>>>> time for good people to take another try at releasing something
>>>> nondefective.
>>>>
>>>> Here to help with the quality control this time around.
>>>> --
>>>> Joe Schaefer, Ph.D.
>>>> <https://sunstarsys.com/orion/features>
>>>> Orion - The Enterprise Jamstack Wiki
>>>> <https://sunstarsys.com/orion/features>
>>>> 
>>>> 954.253.3732 
>>>>
>>>>
>>>> --
>> Joe Schaefer, Ph.D.
>> <https://sunstarsys.com/orion/features>
>> Orion - The Enterprise Jamstack Wiki
>> <https://sunstarsys.com/orion/features>
>> 
>> 954.253.3732 
>>
>>
>> --
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 

Re: Time for a new libapreq2 release?

[Joe Schaefer]

Because my account no longer exists?

On Mon, Aug 28, 2023 at 1:43 AM Greg Stein  wrote:

> you're on the PMC. Why don't you do the tag ?
>
> On Sun, Aug 27, 2023 at 4:31 PM Joe Schaefer  wrote:
>
>> Seems like it’s been a year since the last release, which means it’s time
>> for good people to take another try at releasing something nondefective.
>>
>> Here to help with the quality control this time around.
>> --
>> Joe Schaefer, Ph.D.
>> <https://sunstarsys.com/orion/features>
>> Orion - The Enterprise Jamstack Wiki
>> <https://sunstarsys.com/orion/features>
>> 
>> 954.253.3732 
>>
>>
>> --
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 

Time for a new libapreq2 release?

[Joe Schaefer]

Seems like it’s been a year since the last release, which means it’s time
for good people to take another try at releasing something nondefective.

Here to help with the quality control this time around.
-- 
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

All good.  Just didn’t want to see needless delays in getting this stuff
incorporated while you build out the non-content handler mode for mod_wasm
that IMO will never be in big demand (if it were, mod_perl wouldn’t be such
a stagnant community over the past two decades).

On Fri, Jul 7, 2023 at 4:07 PM Jesús González  wrote:

> Joe, thanks for your feedback!
>
>
>
> Just to make sure I understand this feedback, what you are mentioning is
> that exposing the internals of Apache diminishes the value of the sandbox
> because programs could potentially perform write operations into the
> internals of httpd state, tables, etc. Is that correct?
>
>
>
> If my understanding is correct, this should not be an issue:
>
>
>
> - The current incarnation of mod_wasm is implemented as a content-handler
> and does not have access to the internals of Apache or tables. All the
> information is passed through environment variables, similar to a
> traditional CGI binary, but running in the Wasm sandbox (so you can control
> tightly any access to filesystem, network, etc.).
>
>
>
> - The proposed changes to mod_wasm that enable writing Apache modules in
> other languages would expose the API, but that’s the idea: to make it easy
> to build fully featured Apache modules using any language that can compile
> to Wasm (ie: Go, Python). Think of this as an ‘universal’ polyglot version
> of mod_lua with added sandboxing capabilities.
>
>
>
> Which mode to use can be configured. You definitely don’t want random
> users having access to the internals of httpd when serving their regular
> application (ie: Drupal).
>
>
>
> Having said all of this, regarding the read-only structs, a Wasm binary
> cannot access the host memory space. So, a pointer to an apr table in the
> httpd memory space cannot be dereferenced within the sandbox. There exist
> opaque reference types (ie: externref) to host objects that comply with
> WebAssembly sandboxing guarantees as explained in
> https://fitzgeraldnick.com/2020/08/27/reference-types-in-wasmtime.html.
> This is great in terms of security, but a drawback from a performance
> perspective. To manipulate data structs, either they are copied into the
> Wasm memory and copied back to the server, or we offer a set of limited
> interfaces to the Wasm binary to perform such actions. So yes, we believe
> your proposal of getting the apreq_* (ARP table-based) interfaces exposed
> as read-only data structures is doable and useful.
>
> Cheers!
>
>
>
> *De: *Joe Schaefer 
> *Fecha: *miércoles, 5 de julio de 2023, 4:59
> *Para: *dev@httpd.apache.org 
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
> *!! External Email*
>
> The win with having an apr table  api from httpd is that by sharing those
> tables in the sandbox, various programming languages will be able to
> interact with others without stealing the client form inputs.
>
>
>
> Even if you don’t go that route, and just expose the form inputs on stdin
> in your app, users can always configure apreq’s input filter to activate on
> the protocol filter chain before wasm activates. That way other modules
> still can access form input without breaking the Wasm app.
>
>
>
> On Tue, Jul 4, 2023 at 10:48 PM Joe Schaefer  wrote:
>
> The more of the API you expose, the less value the sandbox has to end
> users.  For Webapps, easy read/search / write/ iterate is essential.  But
> also form data; which apreq stores in readonly apr tables.
>
>
>
> Joe Schaefer, Ph.D
>
> 
>
> +1 (954) 253-3732
>
> SunStar Systems, Inc.
>
> *Orion - The Enterprise Jamstack Wiki*
>
>
> --
>
> *From:* Jesús González 
> *Sent:* Monday, July 3, 2023 8:49:33 AM
> *To:* dev@httpd.apache.org 
> *Subject:* Re: mod_wasm: Contributing Upstream to Apache
>
>
>
> Hola!
>
> mod_wasm v0.12.1
> <https://github.com/vmware-labs/mod_wasm/releases/tag/v0.12.1> is now
> available!
>
> This maintenance release bumps Wasmtime to 10.0.1, including preliminary
> support for WASI preview 2 among other improvements and fixes.
>
> Best,
> Jesús
>
>
>
> *De: *Jesús González 
> *Fecha: *viernes, 2 de junio de 2023, 19:09
> *Para: *dev@httpd.apache.org 
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
> Thanks Joe for your encouragement! And yes, your feedback was what
> inspired us to expand mod_wasm in this direction.
>
> In the demo from my colleague Asen, we expose three wrapper functions to
> WebAssembly get_header, set_header, delete_header, that internally make use
> of apr_table_get, apr_table_set and apr_table_unset with the incoming
> request headers (r->headers_in). This

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

The win with having an apr table  api from httpd is that by sharing those
tables in the sandbox, various programming languages will be able to
interact with others without stealing the client form inputs.

Even if you don’t go that route, and just expose the form inputs on stdin
in your app, users can always configure apreq’s input filter to activate on
the protocol filter chain before wasm activates. That way other modules
still can access form input without breaking the Wasm app.

On Tue, Jul 4, 2023 at 10:48 PM Joe Schaefer  wrote:

> The more of the API you expose, the less value the sandbox has to end
> users.  For Webapps, easy read/search / write/ iterate is essential.  But
> also form data; which apreq stores in readonly apr tables.
>
> Joe Schaefer, Ph.D
> 
> +1 (954) 253-3732
> SunStar Systems, Inc.
> *Orion - The Enterprise Jamstack Wiki*
>
> --
> *From:* Jesús González 
> *Sent:* Monday, July 3, 2023 8:49:33 AM
> *To:* dev@httpd.apache.org 
> *Subject:* Re: mod_wasm: Contributing Upstream to Apache
>
>
> Hola!
>
> mod_wasm v0.12.1
> <https://github.com/vmware-labs/mod_wasm/releases/tag/v0.12.1> is now
> available!
>
> This maintenance release bumps Wasmtime to 10.0.1, including preliminary
> support for WASI preview 2 among other improvements and fixes.
>
> Best,
> Jesús
>
>
>
> *De: *Jesús González 
> *Fecha: *viernes, 2 de junio de 2023, 19:09
> *Para: *dev@httpd.apache.org 
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
> Thanks Joe for your encouragement! And yes, your feedback was what
> inspired us to expand mod_wasm in this direction.
>
> In the demo from my colleague Asen, we expose three wrapper functions to
> WebAssembly get_header, set_header, delete_header, that internally make use
> of apr_table_get, apr_table_set and apr_table_unset with the incoming
> request headers (r->headers_in). This shows read and write capabilities
> from a Wasm binary using internal Apache APIs. Is this what you are
> referring to with exposing apreq_*?
>
> Limiting to read-only (ie: just get_header) implies that some
> functionality that is possible with other extension modules (mod_headers,
> mod_perl, mod_lua, etc.) won’t be available in mod_wasm. We would love to
> know more about those concerns, so we can understand better how to develop
> mod_wasm in a way that both allows you to develop fully capable modules but
> still address any concerns you may have.
>
> BTW, here is a recent article showing how mod_wasm can help mitigating
> vulnerabilities
> https://wasmlabs.dev/articles/mitigating-php-vulnerabilities-with-webassembly/,
> proving how it adds an extra layer of security to traditional applications.
>
> Looking forward to your feedback.
>
>
> *De: *Joe Schaefer 
> *Fecha: *jueves, 1 de junio de 2023, 22:16
> *Para: *dev@httpd.apache.org 
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
> *!! External Email*
>
> Huge fan, love that you are receptive to my feedback.  If you get to the
> point where the apreq_* (APR table-based) interfaces in trunk can be
> exposed as read-only data structures in mod_wasm as an optional API for
> power httpd users that like the sandboxed functionality you get OOTB, that
> would justify a lot of the more conservative concerns that some devs have
> for not putting incorporating this into the trunk codebase, which would be
> my recommendation at that point for how to get it into a releasable tree at
> some point.
>
>
>
>
>
> On Tue, May 30, 2023 at 8:42 AM José Carlos Chávez 
> wrote:
>
> I think not making WASM a first class concern in a proxy or server is
> missing out, more so in those platforms where extensibility isn't trivial.
> Apache will remain running in current setups but having limited
> extensibility is something concerning these days as systems are getting
> more and more complex. Writing an apache module isn't something you do
> every day and it probably takes quite some time, writing a wasm app
> following certain ABI is something you can do in minutes, hence supporting
> mod_wasm as a first class concern could be a good point in the
> sustainability of an ecosystem when it comes to moving forward out of the
> status quo.
>
> On 2022/11/14 06:37:34 Jesús González wrote:
> > Hi everyone,
> >
> >
> >
> > I’m Jesús González, and I am part of VMware’s Wasm Labs: wasmlabs.dev<
> https://wasmlabs.dev/>, a group focused on creating open source tools for
> WebAssembly.
> >
> > We have created mod_wasm, an Apache module for running WebAssembly
> binaries inside httpd, and we would like to contribute it upstream. Please
> see below for more details. We would l

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

The more of the API you expose, the less value the sandbox has to end users.  
For Webapps, easy read/search / write/ iterate is essential.  But also form 
data; which apreq stores in readonly apr tables.

Joe Schaefer, Ph.D

+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki


From: Jesús González 
Sent: Monday, July 3, 2023 8:49:33 AM
To: dev@httpd.apache.org 
Subject: Re: mod_wasm: Contributing Upstream to Apache


Hola!

mod_wasm v0.12.1<https://github.com/vmware-labs/mod_wasm/releases/tag/v0.12.1> 
is now available!

This maintenance release bumps Wasmtime to 10.0.1, including preliminary 
support for WASI preview 2 among other improvements and fixes.

Best,
Jesús



De: Jesús González 
Fecha: viernes, 2 de junio de 2023, 19:09
Para: dev@httpd.apache.org 
Asunto: Re: mod_wasm: Contributing Upstream to Apache

Thanks Joe for your encouragement! And yes, your feedback was what inspired us 
to expand mod_wasm in this direction.

In the demo from my colleague Asen, we expose three wrapper functions to 
WebAssembly get_header, set_header, delete_header, that internally make use of 
apr_table_get, apr_table_set and apr_table_unset with the incoming request 
headers (r->headers_in). This shows read and write capabilities from a Wasm 
binary using internal Apache APIs. Is this what you are referring to with 
exposing apreq_*?

Limiting to read-only (ie: just get_header) implies that some functionality 
that is possible with other extension modules (mod_headers, mod_perl, mod_lua, 
etc.) won’t be available in mod_wasm. We would love to know more about those 
concerns, so we can understand better how to develop mod_wasm in a way that 
both allows you to develop fully capable modules but still address any concerns 
you may have.

BTW, here is a recent article showing how mod_wasm can help mitigating 
vulnerabilities 
https://wasmlabs.dev/articles/mitigating-php-vulnerabilities-with-webassembly/, 
proving how it adds an extra layer of security to traditional applications.

Looking forward to your feedback.



De: Joe Schaefer 
Fecha: jueves, 1 de junio de 2023, 22:16
Para: dev@httpd.apache.org 
Asunto: Re: mod_wasm: Contributing Upstream to Apache

!! External Email

Huge fan, love that you are receptive to my feedback.  If you get to the point 
where the apreq_* (APR table-based) interfaces in trunk can be exposed as 
read-only data structures in mod_wasm as an optional API for power httpd users 
that like the sandboxed functionality you get OOTB, that would justify a lot of 
the more conservative concerns that some devs have for not putting 
incorporating this into the trunk codebase, which would be my recommendation at 
that point for how to get it into a releasable tree at some point.





On Tue, May 30, 2023 at 8:42 AM José Carlos Chávez 
mailto:jcchav...@apache.org>> wrote:

I think not making WASM a first class concern in a proxy or server is missing 
out, more so in those platforms where extensibility isn't trivial. Apache will 
remain running in current setups but having limited extensibility is something 
concerning these days as systems are getting more and more complex. Writing an 
apache module isn't something you do every day and it probably takes quite some 
time, writing a wasm app following certain ABI is something you can do in 
minutes, hence supporting mod_wasm as a first class concern could be a good 
point in the sustainability of an ecosystem when it comes to moving forward out 
of the status quo.

On 2022/11/14 06:37:34 Jesús González wrote:
> Hi everyone,
>
>
>
> I’m Jesús González, and I am part of VMware’s Wasm Labs: 
> wasmlabs.dev<http://wasmlabs.dev/><https://wasmlabs.dev/>, a group focused on 
> creating open source tools for WebAssembly.
>
> We have created mod_wasm, an Apache module for running WebAssembly binaries 
> inside httpd, and we would like to contribute it upstream. Please see below 
> for more details. We would love to get your feedback and understand what 
> improvements would be needed (if any) before it could be considered for 
> contribution to the project.
>
>
>
>
>
> The details:
>
>
>
> WebAssembly<https://webassembly.org/> (Wasm) is a new binary instruction 
> format that is open, portable, efficient, secure, and polyglot. It originated 
> in the browser but is increasingly used in server applications, in particular 
> NGINX, Apache APISIX, Istio provide Wasm-based plugin support (i.e.: 
> https://apisix.apache.org/docs/apisix/wasm/).
>
>
>
> mod_wasm is a way to run WebAssembly modules inside Apache Server. This is 
> similar to how mod_php embeds a PHP runtime to run PHP code. This enables any 
> language that supports WebAssembly (including C++, Rust, Go but also Python, 
> PHP, Ruby) to run with mod_wasm and take advantage of the extra level of 
> security and

Re: libapreq 2.17 POST upload with empty filename parameter

[Joe Schaefer]

2.17 was a dud security release.  Use trunk

Joe Schaefer, Ph.D

+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki


From: Raymond Field via dev 
Sent: Tuesday, July 4, 2023 7:36:33 AM
To: dev@httpd.apache.org 
Subject: libapreq 2.17 POST upload with empty filename parameter

Hi,

I don't know if this is the correct place to report an issue with
libapreq2, please let me know where I should sent this report if this
isn't the correct place.

If I POST a form to the server that contains unfilled file upload fields, the
library seems to give up processing at the first empty filename, e.g. if
I POST

-15448443913271751721417945010
Content-Disposition: form-data; name="postticket"


-15448443913271751721417945010
Content-Disposition: form-data; name="uid"

1263741688468911
-15448443913271751721417945010
Content-Disposition: form-data; name="new_doc_file";
filename="some_test.txt"
Content-Type: text/plain

this is some text


-15448443913271751721417945010
Content-Disposition: form-data; name="new_doc_type"

Document
-15448443913271751721417945010
Content-Disposition: form-data; name="vidlinkhtml"


-15448443913271751721417945010
Content-Disposition: form-data; name="new_doc_thumbnail"; filename=""
Content-Type: application/octet-stream


-15448443913271751721417945010
Content-Disposition: form-data; name="new_doc_file_thumbnail"; filename=""
Content-Type: application/octet-stream


-15448443913271751721417945010
Content-Disposition: form-data; name="new_doc_title"

joe_wicks_crispy_sesame_chicken
-15448443913271751721417945010
Content-Disposition: form-data; name="new_access"

General
-15448443913271751721417945010
Content-Disposition: form-data; name="new_port_name"


-15448443913271751721417945010
Content-Disposition: form-data; name="new_doc_desc"


-15448443913271751721417945010
Content-Disposition: form-data; name="role_7_priv_2"

21
-15448443913271751721417945010
Content-Disposition: form-data; name="new_comments"

YES
-15448443913271751721417945010
Content-Disposition: form-data; name="new_notify"

YES
-15448443913271751721417945010
Content-Disposition: form-data; name="add_submit"

Submit
-15448443913271751721417945010
Content-Disposition: form-data; name="add_submit_button"

Submit
-15448443913271751721417945010--

When looking at $apr->param I only see the following names: postticket
uid new_doc_file vidlinkhtml

i.e. up to but not including the first parameter with filename=""

If I submit the form without the parameters that have empty filenames I
see all of the parameter names.

This started happening when I upgraded a server from Debian 11 to Debian
12, so it worked OK in libapreq 2.13.  The libapreq libraries are not
currently included in the Bookwork package list, so I added them from
testing.  I've also tried installing directly from CPAN, but the same issue.

Kind regards,

Raymond Field

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

Huge fan, love that you are receptive to my feedback.  If you get to the
point where the apreq_* (APR table-based) interfaces in trunk can be
exposed as read-only data structures in mod_wasm as an optional API for
power httpd users that like the sandboxed functionality you get OOTB, that
would justify a lot of the more conservative concerns that some devs have
for not putting incorporating this into the trunk codebase, which would be
my recommendation at that point for how to get it into a releasable tree at
some point.


On Tue, May 30, 2023 at 8:42 AM José Carlos Chávez 
wrote:

> I think not making WASM a first class concern in a proxy or server is
> missing out, more so in those platforms where extensibility isn't trivial.
> Apache will remain running in current setups but having limited
> extensibility is something concerning these days as systems are getting
> more and more complex. Writing an apache module isn't something you do
> every day and it probably takes quite some time, writing a wasm app
> following certain ABI is something you can do in minutes, hence supporting
> mod_wasm as a first class concern could be a good point in the
> sustainability of an ecosystem when it comes to moving forward out of the
> status quo.
>
> On 2022/11/14 06:37:34 Jesús González wrote:
> > Hi everyone,
> >
> >
> >
> > I’m Jesús González, and I am part of VMware’s Wasm Labs: wasmlabs.dev<
> https://wasmlabs.dev/>, a group focused on creating open source tools for
> WebAssembly.
> >
> > We have created mod_wasm, an Apache module for running WebAssembly
> binaries inside httpd, and we would like to contribute it upstream. Please
> see below for more details. We would love to get your feedback and
> understand what improvements would be needed (if any) before it could be
> considered for contribution to the project.
> >
> >
> >
> >
> >
> > The details:
> >
> >
> >
> > WebAssembly (Wasm) is a new binary
> instruction format that is open, portable, efficient, secure, and polyglot.
> It originated in the browser but is increasingly used in server
> applications, in particular NGINX, Apache APISIX, Istio provide Wasm-based
> plugin support (i.e.: https://apisix.apache.org/docs/apisix/wasm/).
> >
> >
> >
> > mod_wasm is a way to run WebAssembly modules inside Apache Server. This
> is similar to how mod_php embeds a PHP runtime to run PHP code. This
> enables any language that supports WebAssembly (including C++, Rust, Go but
> also Python, PHP, Ruby) to run with mod_wasm and take advantage of the
> extra level of security and sandboxing. To learn more about mod_wasm you
> can check out the following resources:
> >
> >   *   An overview article
> for the original release.
> >   *   We presented mod_wasm at ApacheCon this year and here are the
> slides<
> https://apachecon.com/acna2022/slides/01_Gonz%c3%a1lez_mod-wasm_Bringing_WebAssembly.pdf>
> and the source code: https://github.com/vmware-labs/mod_wasm.
> >   *   CNCF Talk on mod_wasm showcasing how to run WordPress:
> https://www.youtube.com/watch?v=jXe8kulUscQ
> >
> >
> >
> > In terms of mod_wasm architecture, the module is split into two parts:
> >
> >   *   mod_wasm.so is the extension module for Apache and it’s written in
> C.
> >   *   An external dependency: libwasm_runtime.so, which is written in
> Rust and needs to be installed into the system.
> >
> >
> >
> > We modelled this after mod_tls, a module that is part of httpd and also
> has a Rust dependency.
> >
> > You can take a look at the architecture diagram and instructions on how
> to build the module here:
> https://github.com/vmware-labs/mod_wasm#%EF%B8%8F-building-mod_wasm
> >
> >
> >
> > In terms of the actual contribution, please find a patch attached. We
> tried to follow all existing conventions in terms of autoconf/automake,
> providing module documentation, etc. Please let us know anything that you
> see missing or could be improved. In particular, we do not know yet if it
> is better to keep the Rust code separate, as an external dependency (like
> mod_tls does) or in the Apache source code repository.
> >
> >
> >
> > In summary, we believe mod_wasm is a worthy addition to httpd and it
> will allow us to catch up to some of the other web servers already
> supporting Wasm, like NGINX. We were encouraged by Rich Bowen, Jim
> Jagielski and Jean-Frederic Clere to submit it for contribution upstream
> and we are looking forward to your feedback.
> >
> >
> >
> > Cheers!
> >
> > Jesús
> >
> >
> >
> >
> >
>

Re: Apache2 chroot problem: towards a solution

[Joe Schaefer]

Awesome that Ubuntu package managers are moonlighting as open source
developer perfectionists instead of working with upstream projects on
issues.

On Thu, May 18, 2023 at 12:47 AM Benjamin Godfrey <
mr.benjamingodf...@gmail.com> wrote:

> Hi, I'm working on the problem of Apache2 ignoring requests to any command
> in the chroot environment.  I have seen complaints about this posted on a
> couple of websites, and I have not seen any solution.   I seem to have
> narrowed the problem down to a relatively small section of the code, but I
> have gotten ambiguous information on how to resolve the issue.
>
> Initially, this problem comes across as a classic system
> compatibility issue, but this it turns out is not the case.   The solution
> seems to be fairly easily solved, but either the Apache2 code would require
> a slight modification, or a module would need to be written, if there isn't
> a module that already solves the problem, that unlocks the Apache for Linux
> users.
>
>
> The errors follow the system information:
>
> Distributor ID: Ubuntu
> Description:Ubuntu 20.04.6 LTS
> Release:20.04
> Codename:   focal
>
> Server version: Apache/2.4.41 (Ubuntu)
>
>
> These are five typical errors:
>
>
> systemctl status
> System has not been booted with systemd as init system (PID 1). Can't
> operate.
> Failed to connect to bus: Host is down
>
>
> sudo systemctl start apache2
> Running in chroot, ignoring request: start
>
>
> sudo apachectl start
> Invoking 'systemctl start apache2'.
> Use 'systemctl status apache2' for more info.
> Running in chroot, ignoring request: start
>
>
> sudo service apache2 restart
>  * Restarting Apache httpd web server apache2
>
>  Invoking 'systemctl start apache2'.
> Use 'systemctl status apache2' for more info.
> Running in chroot, ignoring request: start
>
>
> sudo systemctl status apache2
> Running in chroot, ignoring request: status
>
>
>
> The irony is that the error message is stalling development on important
> issues like the eventual migration to systemd while the text of the message
> seems to point to the cause of the error as related to the systemd  boot
> process not being completed in the chroot.  This isn't the case.  The
> errors are caused by the following code in Apache2:
>
> if (ap_is_in_chroot()) {
>
> ap_log_error(APLOG_MARK, APLOG_ERR, 0, APLOG_NOERRNO,
>
>  "Running in chroot, ignoring request: start");
>
> return APR_SUCCESS;
>
> }
> This code begs the question, why is Apache2 even checking that the "ap" is
> running in a chroot?  It must be understood that using a chroot environment
> is a useful security measure, and checking ap_is_in_chroot in this context
> is limiting the usefulness of Apache for a number of users.
>
> Further information varies, as I haven't been able to locate this segment
> in the code.  I have heard it is in the ap_run_mpm() function,  and in the
> server/mpm/common/main.c file
>
> Other information, of which I am skeptical reports:
>
>The ap_is_in_chroot() function is not a public function. It is an
> internal function that is used by the Apache source code. As such, it is
> not included in the public release of the Apache source code.
>
> I am not sure if there could be a module that would solve this issue, and
> I'm not sure if something like:
>
> if [ -n "$AP_CHROOT_DIR" ]; then
>
>   unset AP_CHROOT_DIR
>
> Fi
> Would be enough to solve the issue?
>
> Benjamin Godfrey
>
>
> --
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 

Re: [VOTE] Switch read/write repository from Subversion to Git

[Joe Schaefer]

I wish more Apache projects reach maintenance mode as part of their maturity 
model.  It’s good to complete your mission instead of always digging deeper 
holes.

Joe Schaefer, Ph.D

+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki


From: Greg Stein 
Sent: Wednesday, May 10, 2023 2:59:24 PM
To: Stefan Sperling 
Cc: dev@httpd.apache.org 
Subject: Re: [VOTE] Switch read/write repository from Subversion to Git

On Wed, May 10, 2023 at 5:18 AM Stefan Sperling 
mailto:s...@apache.org>> wrote:
>...
I did have some hope that we would see individual self-motivated contributors
arriving via various ASF projects because they are all using SVN every day
on svn.apache.org<http://svn.apache.org>, are programmers, might have itches to 
scratch, already have
commit access to ^/subversion, and there is some sense of shared ownership
across the ASF community. I was reminded of all this by Graham's remark.
It's the lack of such interactions that I find disappointing in retrospect.
There certainly have been some, but relatively few.

IMO, it is because Subversion is successful.

It just works. Zero friction. It doesn't cause developers a headache or an 
"itch to scratch".

One doesn't think to improve their dishwasher. It just works. Why change your 
hammer? It works.

I believe that Subversion hit its goal, and then some. I believe that is why 
the *use* of Subversion did not lead to a desire to work/fix/change Subversion.

Cheers,
-g

Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))

[Joe Schaefer]

Get over the heartache and brand loyalty and get on rw git.  Github isn't
the only game in town anymore for git hosting, so don't feel trapped by
infra just because it's all they've got in the tank.

On Tue, Apr 25, 2023 at 2:07 PM Eric Covener  wrote:

> On Tue, Apr 25, 2023 at 2:45 AM Ruediger Pluem  wrote:
> >
> >
> >
> > On 4/12/23 2:02 PM, Yann Ylavic wrote:
> > > On Wed, Apr 12, 2023 at 1:31 PM Eric Covener 
> wrote:
> > >>
> > >> On Wed, Apr 12, 2023 at 6:36 AM Yann Ylavic 
> wrote:
> > >>>
> > >>> On Wed, Apr 12, 2023 at 12:26 PM Yann Ylavic 
> wrote:
> > 
> >  On Wed, Apr 12, 2023 at 12:18 PM ylavic 
> wrote:
> > >
> > > @ylavic approved this pull request.
> > >
> > > Three approvals to get ci started?
> > 
> >  Nope.. It seems that gh actions don't run for PRs whatever we do.
> >  The docs[1] say that there should be an "Approve and run" button
> near
> >  the "workflow awaiting approval" text, but it's not the case for
> httpd
> >  mirror, while approving the whole PR looks inefficient..
> > >>>
> > >>> We (PMC/committers) once had the right to close any PRs, but that
> > >>> seems to not be the case anymore either.
> > >>> Something changed since
> > >>> https://lists.apache.org/thread/g7bb70ymlmkzjlx1rpvq46dwz54qcpdb
> > >>> probably.
> > >>>
> > 
> >  Any more ideas? Help from infra needed?
> > 
> >  Regards;
> >  Yann.
> > 
> >  [1]
> https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks
> > >>
> > >>
> > >> We are chatting with Daniel about it on ASF slack.
> > >
> > > Ah ok, I created https://issues.apache.org/jira/browse/INFRA-24457
> FWIW..
> > >
> >
> > I would like to bring this back here, now that we have an answer in the
> ticket.
> > The root cause for the current situation seems to be that our Github
> repository is just a read only mirror of our Subversion
> > repository. Approving PR's requires write permissions to the Github
> repository.
> >
> > As far as I understand from the ticket we have two options:
> >
> > 1. We establish a monitoring process on PR's that ensures that we detect
> misuse of Github actions by non committers.
> >Then Infra could set the PR's back to "auto-approval".
> >
> > 2. We switch from Subversion to Git and use Git as our read / write main
> repository.
> >
> > My 2 cents on the options:
> >
> > 1. I am not sure which exact monitoring will be sufficient, but it may
> put some larger burden on us to ensure that we
> >detect misuse in a timely manner. Furthermore the question to me will
> be what we can do to stop misuse quickly if we
> >detect it.
> >
> > 2. Switching from Subversion to Git is mostly an emotional problem for
> me. We have some closer ties to Subversion by some
> >overlaps in the community and via mod_dav_svn we kind of partially
> eat our very own dogfood here by using Subversion.
> >We wouldn't do that any longer with Git. Plus it would switch another
> of our development tools from an Apache license to GPL.
> >Apart from technical aspects that this change would create we should
> check if all of the current active committers are fine
> >using Github. While people could use Gitbox and thus avoid Github
> when we use Git I would like us to leverage the features of
> >Github when we would do this switch and I think this cannot be done
> if active committers would have issues with Github.
>
>
> I think r/w github is the way to go, but I know from previous threads
> there are strong feelings against it.
> Right now we seem to not be optimized for either maintainers or
> contributors, it's just inertia. I think it's bad for our image.
>

Re: CPU affinity request

[Joe Schaefer]

Nice proof of concept, but the code needs a serious porting effort to non-Linux 
platforms as well, and they’re all quirky in their own ways about this 
featureset.

Doable tho.

Joe Schaefer, Ph.D

+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki


From: Martin Ma 
Sent: Thursday, February 2, 2023 4:49:33 AM
To: dev@httpd.apache.org 
Subject: CPU affinity request


Hi All,

During httpd performance evaluation in Alibaba Cloud instance, I found httpd 
performance improved significantly after using “taskset” to set CPU affinity 
for httpd processes/threads, because it decreased the amount of CPU migrations. 
Performance improved 60% in arm instance g8y.2xlarge(8 vcpus, 32GiB memory, 
40GB ESSD), also improved 20% in x86 instance g7.2xlarge(8 vcpus, 32GiB memory, 
40GB ESSD). Test case: run httpd with event mode on g8y.2xlarge or g7.2xlarge, 
run traffic generator/benchmark 'wrk' on g8y.4xlarge(16 vcpus, 32GiB memory, 
40GB ESSD), wrk command is 'wrk -t 32 -c 1000 -d 30 --latency 
http://$ServerIP<http://%24serverip/>'

mpm event parameters:

StartServers  8
ServerLimit 100
ThreadLimit2000
MinSpareThreads  75
MaxSpareThreads2000
ThreadsPerChild 125
MaxRequestWorkers  2000


But httpd didn't have related parameters to support CPU affinity, so I used 
"taskset" to optimize.

After source code analysis, I made a prototype for the affinity solution(add 
set_affinity function when worker/lister thread created). We can observe the 
same improvement by this solution. However, this prototype only applied the 
above special “event mpm” configuration for 8 cores server. I think it also 
needs to modify the current mechanism to dynamically adapt to the perceived 
load and add new parameters for the affinity setting.

I had created a ticket on bugzilla, and Christophe JAILLET suggested discussing 
it in the dev mail list. I am not the developer on httpd, hope experts can 
evaluate this request and add cpu affinity function in future versions. Any 
commnet, please let me know.

bugzilla ticket link: https://bz.apache.org/bugzilla/show_bug.cgi?id=66424

Prototype patch(based on version 2.4.37) as below:

diff --git a/server/mpm/event/event.c b/server/mpm/event/event.c
index ffe8a23cbd..d23d115fff 100644
--- a/server/mpm/event/event.c
+++ b/server/mpm/event/event.c
@@ -1586,6 +1586,8 @@ static void * APR_THREAD_FUNC 
listener_thread(apr_thread_t * thd, void *dummy)
 int have_idle_worker = 0;
 apr_time_t last_log;

+ap_setaffinity(process_slot);
+
 last_log = apr_time_now();
 free(ti);

@@ -1998,6 +2000,8 @@ static void *APR_THREAD_FUNC worker_thread(apr_thread_t * 
thd, void *dummy)
 apr_status_t rv;
 int is_idle = 0;

+ap_setaffinity(process_slot);
+
 free(ti);

 ap_scoreboard_image->servers[process_slot][thread_slot].pid = ap_my_pid;
@@ -2456,6 +2460,8 @@ static void child_main(int child_num_arg, int 
child_bucket)
 apr_thread_t *start_thread_id;
 int i;

+ap_setaffinity(process_slot);
+
 /* for benefit of any hooks that run as this child initializes */
 retained->mpm->mpm_state = AP_MPMQ_STARTING;

@@ -3862,6 +3868,17 @@ static const char *set_worker_factor(cmd_parms * cmd, 
void *dummy,
 return NULL;
 }

+void ap_setaffinity(int cpu_affinity)
+{
+cpu_set_t mask;
+
+CPU_ZERO();
+CPU_SET(cpu_affinity, );
+
+sched_setaffinity(0, sizeof(cpu_set_t), );
+
+printf("set thread_id=%d CPU affinity to Core %d\n", gettid(), 
cpu_affinity);
+}

 static const command_rec event_cmds[] = {
 LISTEN_COMMANDS,

--
Thanks & Best Regards
Martin Ma

Re: Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

Part of the really cool things you'd like to have as an app-server author
that knows the APR/APU/HTTPd runtime are subrequests, including the
portions that interact with the filter API.
I'm always writing home-grown app-specific SSI-ish filters via mod_perl to
process application pages as event-driven streams.  It will be interesting
to compare mod_wasm with mod_perl2
in terms of security / sandbox models and weigh them against other
nonfunctional features (memory, latency, CPU, etc).


On Fri, Jan 27, 2023 at 12:28 PM Jesús González  wrote:

> Hi Eric,
>
> Thanks for the feedback. Though Wasm is relatively new it is being adopted
> by other HTTP-related projects, like NGINX and Envoy proxy and even ASF
> projects like APISIX. We want to contribute upstream to bring some of these
> new features to the Apache web server, similarly to how we are working to
> contribute our changes to other projects upstream (SQLite, PHP). We plan to
> continue to development and maintenance regardless of future VMware
> involvement. In fact, the reason we started this project was because our
> manager Daniel Lopez was an early ASF member and he looks at this as a way
> to contribute back to the community. We are initially targeting support for
> regular web apps such as WordPress, but we plan for mod_wasm to enable
> safely extending Apache's own functionality, providing access to the module
> API from Wasm code.
>
> On 2023/01/24 20:36:44 Eric Covener wrote:
> > > We are still very interested in contributing this module upstream and
> helping to maintain it. Please, let us know what improvements or changes
> would be needed for it to be considered ready for inclusion.
> >
> > As a pessimistic PMC member not caring about WASM or these languages,
> > I worry that marrying the lifecycle together is not advantageous for
> > either side. Of course I worry about being stuck with the pieces when
> > employer interest wanes or after turnover. It does not seem like it's
> > strictly necessary to be part of the server distribution (there are
> > many examples of successful out-of-tree modules).
> >
> > However the above is no veto.
> >
>

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

Looking over the WASM Roadmap, it appears that they have a plan for
multithreading within a single target language.  That would allow you to
fully support every silly GIL-addled language runtime out there, which
would be very compelling.

On Fri, Jan 27, 2023 at 1:33 PM Joe Schaefer  wrote:

> A native interface outside of CGI compat for apreq would be a killer new
> feature, because it really finishes our vision for apreq as the
> one-HTML-spec-parser for all native apps, regardless of language choice. Of
> course this would be a new opt-in feature for target languages to take
> advantage of, but it will really set apart the speed freaks in your
> userbase.
>
>

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

A native interface outside of CGI compat for apreq would be a killer new
feature, because it really finishes our vision for apreq as the
one-HTML-spec-parser for all native apps, regardless of language choice. Of
course this would be a new opt-in feature for target languages to take
advantage of, but it will really set apart the speed freaks in your
userbase.

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

Still, the idea is wicked cool if mod_wasm really can isolate the Python,
PHP, etc targets onto individual POSIX threads.

Very exciting stuff for HTTP/2 Webapps.

On Wed, Jan 25, 2023 at 4:31 AM Joe Schaefer  wrote:

> Looked at the PR- the IO is pretty primitive (no streaming anywhere).
> Probably not fatal for Webapps, but it could use some better relations with
> the filter stack and bucket brigades.
>
> Joe Schaefer, Ph.D
> 
> +1 (954) 253-3732
> SunStar Systems, Inc.
> *Orion - The Enterprise Jamstack Wiki*
>
> ------
> *From:* Joe Schaefer 
> *Sent:* Tuesday, January 24, 2023 4:06:13 PM
> *To:* dev@httpd.apache.org 
> *Subject:* Re: mod_wasm: Contributing Upstream to Apache
>
> Would be great to marry it to apreq, too.
>
> On Tue, Jan 24, 2023 at 4:04 PM Joe Schaefer  wrote:
>
> It is impossible to run mod_h2 without it or similar.
>
> On Tue, Jan 24, 2023 at 3:37 PM Eric Covener  wrote:
>
> > We are still very interested in contributing this module upstream and
> helping to maintain it. Please, let us know what improvements or changes
> would be needed for it to be considered ready for inclusion.
>
> As a pessimistic PMC member not caring about WASM or these languages,
> I worry that marrying the lifecycle together is not advantageous for
> either side. Of course I worry about being stuck with the pieces when
> employer interest wanes or after turnover.  It does not seem like it's
> strictly necessary to be part of the server distribution (there are
> many examples of successful out-of-tree modules).
>
> However the above is no veto.
>
> --
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

Looked at the PR- the IO is pretty primitive (no streaming anywhere).  Probably 
not fatal for Webapps, but it could use some better relations with the filter 
stack and bucket brigades.

Joe Schaefer, Ph.D

+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki


From: Joe Schaefer 
Sent: Tuesday, January 24, 2023 4:06:13 PM
To: dev@httpd.apache.org 
Subject: Re: mod_wasm: Contributing Upstream to Apache

Would be great to marry it to apreq, too.

On Tue, Jan 24, 2023 at 4:04 PM Joe Schaefer 
mailto:j...@sunstarsys.com>> wrote:
It is impossible to run mod_h2 without it or similar.

On Tue, Jan 24, 2023 at 3:37 PM Eric Covener 
mailto:cove...@gmail.com>> wrote:
> We are still very interested in contributing this module upstream and helping 
> to maintain it. Please, let us know what improvements or changes would be 
> needed for it to be considered ready for inclusion.

As a pessimistic PMC member not caring about WASM or these languages,
I worry that marrying the lifecycle together is not advantageous for
either side. Of course I worry about being stuck with the pieces when
employer interest wanes or after turnover.  It does not seem like it's
strictly necessary to be part of the server distribution (there are
many examples of successful out-of-tree modules).

However the above is no veto.

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

Would be great to marry it to apreq, too.

On Tue, Jan 24, 2023 at 4:04 PM Joe Schaefer  wrote:

> It is impossible to run mod_h2 without it or similar.
>
> On Tue, Jan 24, 2023 at 3:37 PM Eric Covener  wrote:
>
>> > We are still very interested in contributing this module upstream and
>> helping to maintain it. Please, let us know what improvements or changes
>> would be needed for it to be considered ready for inclusion.
>>
>> As a pessimistic PMC member not caring about WASM or these languages,
>> I worry that marrying the lifecycle together is not advantageous for
>> either side. Of course I worry about being stuck with the pieces when
>> employer interest wanes or after turnover.  It does not seem like it's
>> strictly necessary to be part of the server distribution (there are
>> many examples of successful out-of-tree modules).
>>
>> However the above is no veto.
>>
>

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

It is impossible to run mod_h2 without it or similar.

On Tue, Jan 24, 2023 at 3:37 PM Eric Covener  wrote:

> > We are still very interested in contributing this module upstream and
> helping to maintain it. Please, let us know what improvements or changes
> would be needed for it to be considered ready for inclusion.
>
> As a pessimistic PMC member not caring about WASM or these languages,
> I worry that marrying the lifecycle together is not advantageous for
> either side. Of course I worry about being stuck with the pieces when
> employer interest wanes or after turnover.  It does not seem like it's
> strictly necessary to be part of the server distribution (there are
> many examples of successful out-of-tree modules).
>
> However the above is no veto.
>

Re: CVE-2022-22728: libapreq2: libapreq2 multipart form parse memory corruption

[Joe Schaefer]

2.17 is a dud.  What’s in trunk works fine though.

Joe Schaefer, Ph.D

+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki


From: enge...@gsuite.cloud.apache.org  on 
behalf of Apache Security Team 
Sent: Monday, January 2, 2023 7:30:43 AM
To: dev@httpd.apache.org 
Cc: Apache Security Team 
Subject: Re: CVE-2022-22728: libapreq2: libapreq2 multipart form parse memory 
corruption

Hi,

I noticed there was some confusion online as to whether this issue is
fixed in 2.17 (https://www.openwall.com/lists/oss-security/2022/08/26/4).

Unless anyone objects I'll amend the CVE text to make it explicit that
users are recommended to update to 2.17 or later.

Luckily with the new CVE format the version ranges are more explicit,
so this kind of confusion is less likely to occur again.


Kind regards,

Arnout

On Thu, Aug 25, 2022 at 4:09 PM Joe Orton  wrote:
>
> Severity: important
>
> Description:
>
> A flaw in libapreq2 versions 2.16 and earlier could cause a buffer overflow 
> while processing multipart form uploads.  A remote attacker could send a 
> request causing a process crash which could lead to a denial of service 
> attack.
>

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

vel of security and sandboxing. To learn more about mod_wasm you can
> check out the following resources:
>
>- An overview article
>
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwasmlabs.dev%2Farticles%2Fapache-mod-wasm%2F=05%7C01%7Cjesusgm%40vmware.com%7C07586834510d4ffc0a5108dac60ac618%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638040046834229085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=d2MpWnkiKJA4fDOUdNghYPg0p4fMsGTeGiFR6kfcwyg%3D=0>
> for the original release.
>- We presented mod_wasm at ApacheCon this year and here are the slides
>
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapachecon.com%2Facna2022%2Fslides%2F01_Gonz%25C3%25A1lez_mod-wasm_Bringing_WebAssembly.pdf=05%7C01%7Cjesusgm%40vmware.com%7C07586834510d4ffc0a5108dac60ac618%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638040046834229085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=c9U4xL6091Lei7hPlQ83PP6naUCI0SMIxmW0qvRJCq4%3D=0>
> and the source code: https://github.com/vmware-labs/mod_wasm
>
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvmware-labs%2Fmod_wasm=05%7C01%7Cjesusgm%40vmware.com%7C07586834510d4ffc0a5108dac60ac618%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638040046834229085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=5oF9oB7rTpJZfUyECkvOfSnEkdaRT1UhIgOIVBD%2F9fs%3D=0>
>.
>- CNCF Talk on mod_wasm showcasing how to run WordPress:
>https://www.youtube.com/watch?v=jXe8kulUscQ
>
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DjXe8kulUscQ=05%7C01%7Cjesusgm%40vmware.com%7C07586834510d4ffc0a5108dac60ac618%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638040046834229085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=GTh0dro4fqACMKnluAvXITVQFNOUL1BEiijKuSgdVkA%3D=0>
>
>
>
> In terms of mod_wasm architecture, the module is split into two parts:
>
>- *mod_wasm.so* is the extension module for Apache and it’s written in
>C.
>- An external dependency: *libwasm_runtime.so*, which is written in
>Rust and needs to be installed into the system.
>
>
>
> We modelled this after mod_tls, a module that is part of httpd and also
> has a Rust dependency.
>
> You can take a look at the architecture diagram and instructions on how to
> build the module here:
> https://github.com/vmware-labs/mod_wasm#%EF%B8%8F-building-mod_wasm
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvmware-labs%2Fmod_wasm%23%25EF%25B8%258F-building-mod_wasm=05%7C01%7Cjesusgm%40vmware.com%7C07586834510d4ffc0a5108dac60ac618%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638040046834229085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=riwxB9vHMxT%2ByvYzGUXBXtgqMi%2B9%2BRVb1zUZSaTxTHE%3D=0>
>
>
>
> In terms of the actual contribution, please find a patch attached. We
> tried to follow all existing conventions in terms of autoconf/automake,
> providing module documentation, etc. Please let us know anything that you
> see missing or could be improved. In particular, we do not know yet if it
> is better to keep the Rust code separate, as an external dependency (like
> mod_tls does) or in the Apache source code repository.
>
>
>
> In summary, we believe mod_wasm is a worthy addition to httpd and it will
> allow us to catch up to some of the other web servers already supporting
> Wasm, like NGINX. We were encouraged by Rich Bowen, Jim Jagielski and
> Jean-Frederic Clere to submit it for contribution upstream and we are
> looking forward to your feedback.
>
>
>
> Cheers!
>
> Jesús
>
>
>
>
>
-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

Last patch: this one includes autoconf/automake repairs as well.

On Fri, Nov 4, 2022 at 9:02 PM Joe Schaefer  wrote:

> Sometime before end of year, perhaps I can upgrade apreq's autotool deps
> to something Ubuntu 22 can handle,
> for the purpose of dockerizing a build environment for the self-contained
> test suite in library/t.  Getting automated builds that run those
> tests, at least periodically, will make a substantial difference in the
> quality of the development effort for apreq, even in httpd's trunk.
>
> On Fri, Nov 4, 2022 at 3:40 PM Joe Schaefer  wrote:
>
>> One of these tests actually reported a problem with the "whimsical" patch
>> under consideration, Yann.
>> But instead of confronting you about it, Joe O just removed that test
>> from the suite prior to release.
>>
>> This is the very last time I expect to say something critical about
>> 2.17.  Let's make it the last time I say
>> something critical about the team effort into producing any rapreq elease
>> going forward.  You guys know better,
>> and all I ask is that you keep your own standards intact for apreq
>> (without adding any formal process to ensure it).
>> In the end, we're all volunteers- but don't dismiss the work of your
>> predecessors so quickly in the future.
>>
>>
>> On Fri, Nov 4, 2022 at 2:01 PM  wrote:
>>
>>> There's literally over 1M tests in library/t/parsers.c; all of them are
>>> trivial to adjust to taste.
>>> Going forward, if you want to establish different types of parser
>>> behaviors, positively document those behaviors in the test suite, just like
>>> your predecessors did.
>>> Let's not make what happened with 2.17 a new status quo for your efforts.
>>>
>>> -Original Message-
>>> From: Yann Ylavic 
>>> Sent: Wednesday, November 2, 2022 9:47 AM
>>> To: dev@httpd.apache.org
>>> Cc: Joe Schaefer 
>>> Subject: Re: [libapreq2] nits to pick about the patches to util.c over
>>> the past few years
>>>
>>> On Mon, Oct 31, 2022 at 7:44 PM Joe Schaefer  wrote:
>>> >
>>> > The reason this took so long for the community to diagnose isn't
>>> > because of ill-intent, but because it constituted a change of behavior
>>> in the parser logic that wasn't surfaced in the Changes file.
>>>
>>> Please review r1905018 (with a CHANGES entry this time), along with
>>> r1905019 and r1905020 eventually.
>>> I'd suggest subscribing to c...@httpd.apache.org (if not already) and
>>> filter/mark subjects with "/httpd/apreq" if you don't want to miss anything.
>>>
>>> >
>>> > There is never going to come a time when there is any need for urgent
>>> > action on apreq- if it was easy to zero-day it, it would have happened
>>> > by now.  Thus, take as much time as you need between releases to
>>> > communicate with the community about the nature of the deltas you
>>> intend to ship with any GA release.  You have my email address if you need
>>> to spitball any patchsets you are toying with; it's a lot less painful to
>>> get my input in advance than after the fact.
>>>
>>> That's not how it usually works though: r1895107 is dated "Nov 17,
>>> 2021", the [VOTE] for v2.17 started "Aug 18, 2022" and ended Aug 25, which
>>> left you 8 months to review the changes in trunk (and chime in..).
>>>
>>>
>>> Regards;
>>> Yann.
>>>
>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> 
>> 954.253.3732 
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 
Index: configure.ac
===
--- configure.ac(revision 1905068)
+++ configure.ac(working copy)
@@ -1,7 +1,7 @@
 dnl Process this file with autoconf to produce a configure script.
 
-AC_PREREQ(2.53)
-AC_INIT(Apache HTTP Server Request Library, 2.18, apreq-...@httpd.apache.org, 
libapreq2)
+AC_PREREQ([2.71])
+AC_INIT([Apache HTTP Server Request 
Library],[2.18],[apreq-...@httpd.apache.org],[libapreq2])
 dnl Generate config.nice script- macro must be here at the top
 dnl to avoid corruption of $0 and $@.
 APR_CONFIG_NICE(config.nice)
@@ -19,7 +19,7 @@
 
 dnl Checks for programs.
 AC_PROG_CC
-AM_PROG_LIBTOOL
+LT_INIT
 AC_PROG_RANLIB
 AC_PROG_INSTALL
 AC_PROG_LN_S
Index: library/t/parsers.c

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

Sometime before end of year, perhaps I can upgrade apreq's autotool deps to
something Ubuntu 22 can handle,
for the purpose of dockerizing a build environment for the self-contained
test suite in library/t.  Getting automated builds that run those
tests, at least periodically, will make a substantial difference in the
quality of the development effort for apreq, even in httpd's trunk.

On Fri, Nov 4, 2022 at 3:40 PM Joe Schaefer  wrote:

> One of these tests actually reported a problem with the "whimsical" patch
> under consideration, Yann.
> But instead of confronting you about it, Joe O just removed that test from
> the suite prior to release.
>
> This is the very last time I expect to say something critical about 2.17.
> Let's make it the last time I say
> something critical about the team effort into producing any rapreq elease
> going forward.  You guys know better,
> and all I ask is that you keep your own standards intact for apreq
> (without adding any formal process to ensure it).
> In the end, we're all volunteers- but don't dismiss the work of your
> predecessors so quickly in the future.
>
>
> On Fri, Nov 4, 2022 at 2:01 PM  wrote:
>
>> There's literally over 1M tests in library/t/parsers.c; all of them are
>> trivial to adjust to taste.
>> Going forward, if you want to establish different types of parser
>> behaviors, positively document those behaviors in the test suite, just like
>> your predecessors did.
>> Let's not make what happened with 2.17 a new status quo for your efforts.
>>
>> -Original Message-----
>> From: Yann Ylavic 
>> Sent: Wednesday, November 2, 2022 9:47 AM
>> To: dev@httpd.apache.org
>> Cc: Joe Schaefer 
>> Subject: Re: [libapreq2] nits to pick about the patches to util.c over
>> the past few years
>>
>> On Mon, Oct 31, 2022 at 7:44 PM Joe Schaefer  wrote:
>> >
>> > The reason this took so long for the community to diagnose isn't
>> > because of ill-intent, but because it constituted a change of behavior
>> in the parser logic that wasn't surfaced in the Changes file.
>>
>> Please review r1905018 (with a CHANGES entry this time), along with
>> r1905019 and r1905020 eventually.
>> I'd suggest subscribing to c...@httpd.apache.org (if not already) and
>> filter/mark subjects with "/httpd/apreq" if you don't want to miss anything.
>>
>> >
>> > There is never going to come a time when there is any need for urgent
>> > action on apreq- if it was easy to zero-day it, it would have happened
>> > by now.  Thus, take as much time as you need between releases to
>> > communicate with the community about the nature of the deltas you
>> intend to ship with any GA release.  You have my email address if you need
>> to spitball any patchsets you are toying with; it's a lot less painful to
>> get my input in advance than after the fact.
>>
>> That's not how it usually works though: r1895107 is dated "Nov 17, 2021",
>> the [VOTE] for v2.17 started "Aug 18, 2022" and ended Aug 25, which left
>> you 8 months to review the changes in trunk (and chime in..).
>>
>>
>> Regards;
>> Yann.
>>
>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

One of these tests actually reported a problem with the "whimsical" patch
under consideration, Yann.
But instead of confronting you about it, Joe O just removed that test from
the suite prior to release.

This is the very last time I expect to say something critical about 2.17.
Let's make it the last time I say
something critical about the team effort into producing any rapreq elease
going forward.  You guys know better,
and all I ask is that you keep your own standards intact for apreq (without
adding any formal process to ensure it).
In the end, we're all volunteers- but don't dismiss the work of your
predecessors so quickly in the future.


On Fri, Nov 4, 2022 at 2:01 PM  wrote:

> There's literally over 1M tests in library/t/parsers.c; all of them are
> trivial to adjust to taste.
> Going forward, if you want to establish different types of parser
> behaviors, positively document those behaviors in the test suite, just like
> your predecessors did.
> Let's not make what happened with 2.17 a new status quo for your efforts.
>
> -Original Message-
> From: Yann Ylavic 
> Sent: Wednesday, November 2, 2022 9:47 AM
> To: dev@httpd.apache.org
> Cc: Joe Schaefer 
> Subject: Re: [libapreq2] nits to pick about the patches to util.c over the
> past few years
>
> On Mon, Oct 31, 2022 at 7:44 PM Joe Schaefer  wrote:
> >
> > The reason this took so long for the community to diagnose isn't
> > because of ill-intent, but because it constituted a change of behavior
> in the parser logic that wasn't surfaced in the Changes file.
>
> Please review r1905018 (with a CHANGES entry this time), along with
> r1905019 and r1905020 eventually.
> I'd suggest subscribing to c...@httpd.apache.org (if not already) and
> filter/mark subjects with "/httpd/apreq" if you don't want to miss anything.
>
> >
> > There is never going to come a time when there is any need for urgent
> > action on apreq- if it was easy to zero-day it, it would have happened
> > by now.  Thus, take as much time as you need between releases to
> > communicate with the community about the nature of the deltas you intend
> to ship with any GA release.  You have my email address if you need to
> spitball any patchsets you are toying with; it's a lot less painful to get
> my input in advance than after the fact.
>
> That's not how it usually works though: r1895107 is dated "Nov 17, 2021",
> the [VOTE] for v2.17 started "Aug 18, 2022" and ended Aug 25, which left
> you 8 months to review the changes in trunk (and chime in..).
>
>
> Regards;
> Yann.
>


-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

Better version (backs out most of an incorrect prior change).

On Fri, Nov 4, 2022 at 11:38 AM Joe Schaefer  wrote:

> Please add this additional regression test (for the mfd parser with empty
> parts).
>
>
> On Fri, Nov 4, 2022 at 11:12 AM Joe Schaefer  wrote:
>
>> What's in HEAD as of now looks promising.  I'll be happy to dogfood this
>> once we're in the candidacy stage.
>> The point of having apreq in trunk isn't just for mod_perl, but for
>> anyone who wants to take web application development
>> seriously from the apache module viewpoint.  It ticks all the boxes:
>> thread-safe, subrequest-friendly, and is mostly
>> easy to use. It just needs to be refined and matured to the point where
>> the quality controls necessary for shipping in httpd3
>> are at a comfortable level for httpd developers.  If there's a lot more
>> to do, reach out privately to discuss.  Otherwise,
>> lean on me for whatever peer review is missing from the normal release
>> cycles for libapreq2 as you see fit.  I can't promise
>> how long you have my attention, but for the next few releases I'll try to
>> participate in the vetting process.
>>
>>
>>
>>
>>
>> On Wed, Nov 2, 2022 at 10:22 AM Joe Schaefer  wrote:
>>
>>>
>>>
>>> Get Outlook for iOS <https://aka.ms/o0ukef>
>>> --
>>> *From:* Yann Ylavic 
>>> *Sent:* Wednesday, November 2, 2022 9:47 AM
>>> *To:* dev@httpd.apache.org 
>>> *Cc:* Joe Schaefer 
>>> *Subject:* Re: [libapreq2] nits to pick about the patches to util.c
>>> over the past few years
>>>
>>> On Mon, Oct 31, 2022 at 7:44 PM Joe Schaefer  wrote:
>>> >
>>> > The reason this took so long for the community to diagnose isn't
>>> because of ill-intent, but because it constituted
>>> > a change of behavior in the parser logic that wasn't surfaced in the
>>> Changes file.
>>>
>>> Please review r1905018 (with a CHANGES entry this time), along with
>>> r1905019 and r1905020 eventually.
>>> I'd suggest subscribing to c...@httpd.apache.org (if not already) and
>>> filter/mark subjects with "/httpd/apreq" if you don't want to miss
>>> anything.
>>>
>>> >
>>> > There is never going to come a time when there is any need for urgent
>>> action on apreq- if it was easy to zero-day
>>> > it, it would have happened by now.  Thus, take as much time as you
>>> need between releases to communicate with
>>> > the community about the nature of the deltas you intend to ship with
>>> any GA release.  You have my email address
>>> > if you need to spitball any patchsets you are toying with; it's a lot
>>> less painful to get my input in advance than after the fact.
>>>
>>> That's not how it usually works though: r1895107 is dated "Nov 17,
>>> 2021", the [VOTE] for v2.17 started "Aug 18, 2022" and ended Aug 25,
>>> which left you 8 months to review the changes in trunk (and chime
>>> in..).
>>>
>>> There’s nothing usual about this situation, Yann.  I’ve retired from the
>>> foundation many years ago.
>>> I’m here now because of the hatchet job in the 2.17 announce and CVE
>>> description, and resulting need for me to parachute back in again to assist.
>>>
>>> If you want me in person to review something, for your own benefit as
>>> someone who deals in apreq, I’m happy to.  That will instantly drop any
>>> charges of treating users like Guinea pigs, and also mean I will be more
>>> respectful of your work overall.
>>>
>>>
>>> Regards;
>>> Yann.
>>>
>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> 
>> 954.253.3732 
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 
Index: t/parsers.c
===
--- t/parsers.c (revision 1905068)
+++ t/parsers.c (working copy)
@@ -37,15 +37,14 @@
 "content-transfer-encoding: quoted-printable" CRLF CRLF
 "Joe owes =80100." CRLF
 "--AaB03x" CRLF
+"content-disposition: form-data; name=\"\"; filename=\"\"" CRLF
+"Content-Type: text/plain" CRLF CRLF
+"... contents of empty parts ..." CRLF CRLF
+"--AaB03x" CRLF
 "content-disposit

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

Please add this additional regression test (for the mfd parser with empty
parts).


On Fri, Nov 4, 2022 at 11:12 AM Joe Schaefer  wrote:

> What's in HEAD as of now looks promising.  I'll be happy to dogfood this
> once we're in the candidacy stage.
> The point of having apreq in trunk isn't just for mod_perl, but for anyone
> who wants to take web application development
> seriously from the apache module viewpoint.  It ticks all the boxes:
> thread-safe, subrequest-friendly, and is mostly
> easy to use. It just needs to be refined and matured to the point where
> the quality controls necessary for shipping in httpd3
> are at a comfortable level for httpd developers.  If there's a lot more to
> do, reach out privately to discuss.  Otherwise,
> lean on me for whatever peer review is missing from the normal release
> cycles for libapreq2 as you see fit.  I can't promise
> how long you have my attention, but for the next few releases I'll try to
> participate in the vetting process.
>
>
>
>
>
> On Wed, Nov 2, 2022 at 10:22 AM Joe Schaefer  wrote:
>
>>
>>
>> Get Outlook for iOS <https://aka.ms/o0ukef>
>> --
>> *From:* Yann Ylavic 
>> *Sent:* Wednesday, November 2, 2022 9:47 AM
>> *To:* dev@httpd.apache.org 
>> *Cc:* Joe Schaefer 
>> *Subject:* Re: [libapreq2] nits to pick about the patches to util.c over
>> the past few years
>>
>> On Mon, Oct 31, 2022 at 7:44 PM Joe Schaefer  wrote:
>> >
>> > The reason this took so long for the community to diagnose isn't
>> because of ill-intent, but because it constituted
>> > a change of behavior in the parser logic that wasn't surfaced in the
>> Changes file.
>>
>> Please review r1905018 (with a CHANGES entry this time), along with
>> r1905019 and r1905020 eventually.
>> I'd suggest subscribing to c...@httpd.apache.org (if not already) and
>> filter/mark subjects with "/httpd/apreq" if you don't want to miss
>> anything.
>>
>> >
>> > There is never going to come a time when there is any need for urgent
>> action on apreq- if it was easy to zero-day
>> > it, it would have happened by now.  Thus, take as much time as you need
>> between releases to communicate with
>> > the community about the nature of the deltas you intend to ship with
>> any GA release.  You have my email address
>> > if you need to spitball any patchsets you are toying with; it's a lot
>> less painful to get my input in advance than after the fact.
>>
>> That's not how it usually works though: r1895107 is dated "Nov 17,
>> 2021", the [VOTE] for v2.17 started "Aug 18, 2022" and ended Aug 25,
>> which left you 8 months to review the changes in trunk (and chime
>> in..).
>>
>> There’s nothing usual about this situation, Yann.  I’ve retired from the
>> foundation many years ago.
>> I’m here now because of the hatchet job in the 2.17 announce and CVE
>> description, and resulting need for me to parachute back in again to assist.
>>
>> If you want me in person to review something, for your own benefit as
>> someone who deals in apreq, I’m happy to.  That will instantly drop any
>> charges of treating users like Guinea pigs, and also mean I will be more
>> respectful of your work overall.
>>
>>
>> Regards;
>> Yann.
>>
>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 
Index: t/parsers.c
===
--- t/parsers.c (revision 1905068)
+++ t/parsers.c (working copy)
@@ -37,6 +37,10 @@
 "content-transfer-encoding: quoted-printable" CRLF CRLF
 "Joe owes =80100." CRLF
 "--AaB03x" CRLF
+"content-disposition: form-data; name=\"\"; filename=\"\"" CRLF
+"Content-Type: text/plain" CRLF CRLF
+"... contents of empty parts ..." CRLF CRLF
+"--AaB03x" CRLF
 "content-disposition: form-data; name=\"pics\"; filename=\"file1.txt\"" CRLF
 "Content-Type: text/plain" CRLF CRLF
 "... contents of file1.txt ..." CRLF CRLF
@@ -44,7 +48,7 @@
 
 /* This (invalid) case used to segfault the parser before r164254 so should
be tested separately to form_data:
-   
+
 static char form_data_fail[] =
 "content-disposition: form-data; name=\"\"" CRLF
 "content-type: text/plain;" CRLF " charset=windows-1250" CRLF
@@ -237,7 +241,7 @@
 AT_int_eq(rv, (j < strlen(form_data)) ? APR_INCOMPLETE : 
APR_SUCCESS);
 rv = apreq_parser_run(parser, body, tail);
 AT_int_eq(rv, APR_SUCCESS);
-AT_int_eq(apr_table_elts(body)->nelts, 2);
+AT_int_eq(apr_table_elts(body)->nelts, 3);
 
 val = apr_table_get(body,"field1");
 AT_str_eq(val, "Joe owes =80100.");
@@ -560,5 +564,3 @@
 
 return 0;
 }
-
-

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

What's in HEAD as of now looks promising.  I'll be happy to dogfood this
once we're in the candidacy stage.
The point of having apreq in trunk isn't just for mod_perl, but for anyone
who wants to take web application development
seriously from the apache module viewpoint.  It ticks all the boxes:
thread-safe, subrequest-friendly, and is mostly
easy to use. It just needs to be refined and matured to the point where the
quality controls necessary for shipping in httpd3
are at a comfortable level for httpd developers.  If there's a lot more to
do, reach out privately to discuss.  Otherwise,
lean on me for whatever peer review is missing from the normal release
cycles for libapreq2 as you see fit.  I can't promise
how long you have my attention, but for the next few releases I'll try to
participate in the vetting process.





On Wed, Nov 2, 2022 at 10:22 AM Joe Schaefer  wrote:

>
>
> Get Outlook for iOS <https://aka.ms/o0ukef>
> --
> *From:* Yann Ylavic 
> *Sent:* Wednesday, November 2, 2022 9:47 AM
> *To:* dev@httpd.apache.org 
> *Cc:* Joe Schaefer 
> *Subject:* Re: [libapreq2] nits to pick about the patches to util.c over
> the past few years
>
> On Mon, Oct 31, 2022 at 7:44 PM Joe Schaefer  wrote:
> >
> > The reason this took so long for the community to diagnose isn't because
> of ill-intent, but because it constituted
> > a change of behavior in the parser logic that wasn't surfaced in the
> Changes file.
>
> Please review r1905018 (with a CHANGES entry this time), along with
> r1905019 and r1905020 eventually.
> I'd suggest subscribing to c...@httpd.apache.org (if not already) and
> filter/mark subjects with "/httpd/apreq" if you don't want to miss
> anything.
>
> >
> > There is never going to come a time when there is any need for urgent
> action on apreq- if it was easy to zero-day
> > it, it would have happened by now.  Thus, take as much time as you need
> between releases to communicate with
> > the community about the nature of the deltas you intend to ship with any
> GA release.  You have my email address
> > if you need to spitball any patchsets you are toying with; it's a lot
> less painful to get my input in advance than after the fact.
>
> That's not how it usually works though: r1895107 is dated "Nov 17,
> 2021", the [VOTE] for v2.17 started "Aug 18, 2022" and ended Aug 25,
> which left you 8 months to review the changes in trunk (and chime
> in..).
>
> There’s nothing usual about this situation, Yann.  I’ve retired from the
> foundation many years ago.
> I’m here now because of the hatchet job in the 2.17 announce and CVE
> description, and resulting need for me to parachute back in again to assist.
>
> If you want me in person to review something, for your own benefit as
> someone who deals in apreq, I’m happy to.  That will instantly drop any
> charges of treating users like Guinea pigs, and also mean I will be more
> respectful of your work overall.
>
>
> Regards;
> Yann.
>


-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Yann Ylavic 
Sent: Wednesday, November 2, 2022 9:47 AM
To: dev@httpd.apache.org 
Cc: Joe Schaefer 
Subject: Re: [libapreq2] nits to pick about the patches to util.c over the past 
few years

On Mon, Oct 31, 2022 at 7:44 PM Joe Schaefer  wrote:
>
> The reason this took so long for the community to diagnose isn't because of 
> ill-intent, but because it constituted
> a change of behavior in the parser logic that wasn't surfaced in the Changes 
> file.

Please review r1905018 (with a CHANGES entry this time), along with
r1905019 and r1905020 eventually.
I'd suggest subscribing to c...@httpd.apache.org (if not already) and
filter/mark subjects with "/httpd/apreq" if you don't want to miss
anything.

>
> There is never going to come a time when there is any need for urgent action 
> on apreq- if it was easy to zero-day
> it, it would have happened by now.  Thus, take as much time as you need 
> between releases to communicate with
> the community about the nature of the deltas you intend to ship with any GA 
> release.  You have my email address
> if you need to spitball any patchsets you are toying with; it's a lot less 
> painful to get my input in advance than after the fact.

That's not how it usually works though: r1895107 is dated "Nov 17,
2021", the [VOTE] for v2.17 started "Aug 18, 2022" and ended Aug 25,
which left you 8 months to review the changes in trunk (and chime
in..).

There’s nothing usual about this situation, Yann.  I’ve retired from the 
foundation many years ago.
I’m here now because of the hatchet job in the 2.17 announce and CVE 
description, and resulting need for me to parachute back in again to assist.

If you want me in person to review something, for your own benefit as someone 
who deals in apreq, I’m happy to.  That will instantly drop any charges of 
treating users like Guinea pigs, and also mean I will be more respectful of 
your work overall.


Regards;
Yann.

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

The reason this took so long for the community to diagnose isn't because of
ill-intent, but because it constituted
a change of behavior in the parser logic that wasn't surfaced in the
Changes file.

There is never going to come a time when there is any need for urgent
action on apreq- if it was easy to zero-day
it, it would have happened by now.  Thus, take as much time as you need
between releases to communicate with
the community about the nature of the deltas you intend to ship with any GA
release.  You have my email address
if you need to spitball any patchsets you are toying with; it's a lot less
painful to get my input in advance than after the fact.


On Mon, Oct 31, 2022 at 1:56 PM Joe Schaefer  wrote:

> With regard to the faulty patch this revolves around:
> https://svn.apache.org/viewvc?view=revision=1895107
> I do not expect you to know the specs, know the code, nor know what this
> patch actually does, in order to reject it from a GA release.
>
> I expect you to say to yourselves: High Risk, Low Reward, unmotivated
> patches are not appropriate in maintenance releases.
>
>
> On Mon, Oct 31, 2022 at 12:58 PM Joe Schaefer  wrote:
>
>> This stuff was written for an RFC era of the mid 2000s, and a lot of the
>> uncertainties around industry direction have been clarified in the years
>> since then, particularly as they relate to cookie standards.
>>
>> The nastiest code in here is the cookie parser logic that was required
>> back then.  If anything should be radically refactored and simplified,
>> start there.
>>
>> On Mon, Oct 31, 2022 at 12:36 PM Joe Schaefer  wrote:
>>
>>>
>>>
>>> Get Outlook for iOS <https://aka.ms/o0ukef>
>>> --
>>> *From:* Ruediger Pluem 
>>> *Sent:* Monday, October 31, 2022 12:21 PM
>>> *To:* dev@httpd.apache.org 
>>> *Subject:* Re: [libapreq2] nits to pick about the patches to util.c
>>> over the past few years
>>>
>>>
>>>
>>> On 10/30/22 4:28 PM, Joe Schaefer wrote:
>>> > And to be frank- framing my input as me slagging on Yann is
>>> grotesque.  You ship GA releases as a team, and so when you ship a dud
>>> > like 2.17 you should take your lumps as a team.
>>>
>>> I admit that the libapreq2 codebase doesn't get that much review
>>> attention as other parts of httpd and does not draw that much
>>> developer interest. Hence we were very grateful that Yann took some time
>>> to do the needful, fixed the security issue and took it
>>> to a release to get that issue fixed for the users. Thank you Yann for
>>> this. The fact that at least the existing tests still
>>> passed after the changes was at least for me a good indicator that the
>>> changes don't break stuff and are fine.
>>> I also understand if you feel upset if the codebase you wrote and regard
>>> as better was changed and if you feel that the code
>>> deserves more love and care.
>>> The way to fix this is to participate here in a constructive way to get
>>> it in the direction you want it to be.
>>> If you feel that this isn't the correct community for this codebase we
>>> can also talk about this as Eric indicated.
>>> I am with Joe Orton and Greg that you are around for long enough to know
>>> that the way you started this brought attention to your
>>> desires but was counterproductive in many ways (tone of the emails,
>>> number of emails, top postings, too broad statements) to get
>>> things were you want them to be.
>>>
>>>
>>>
>>>
>>> Thanks Rüdiger.  I’m not interested in any type of stewardship for this
>>> code; my interests have long since moved on.  But my approach to software
>>> projects is to finish them, not for them to be perpetual motion machines,
>>> so I’m going to be concerned about frequent release cadences and constant
>>> churn that entails.
>>>
>>> I honestly do not expect apreq to be all that burdensome to maintain for
>>> you guys, regardless of all of the hot button items being fleshed out by
>>> the fact that it’s sitting in your trunk. I think that only helps mature
>>> and refine the product, regardless of how you deliver it to users.
>>>
>>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> 
>> 954.253.3732 
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

With regard to the faulty patch this revolves around:
https://svn.apache.org/viewvc?view=revision=1895107
I do not expect you to know the specs, know the code, nor know what this
patch actually does, in order to reject it from a GA release.

I expect you to say to yourselves: High Risk, Low Reward, unmotivated
patches are not appropriate in maintenance releases.


On Mon, Oct 31, 2022 at 12:58 PM Joe Schaefer  wrote:

> This stuff was written for an RFC era of the mid 2000s, and a lot of the
> uncertainties around industry direction have been clarified in the years
> since then, particularly as they relate to cookie standards.
>
> The nastiest code in here is the cookie parser logic that was required
> back then.  If anything should be radically refactored and simplified,
> start there.
>
> On Mon, Oct 31, 2022 at 12:36 PM Joe Schaefer  wrote:
>
>>
>>
>> Get Outlook for iOS <https://aka.ms/o0ukef>
>> --
>> *From:* Ruediger Pluem 
>> *Sent:* Monday, October 31, 2022 12:21 PM
>> *To:* dev@httpd.apache.org 
>> *Subject:* Re: [libapreq2] nits to pick about the patches to util.c over
>> the past few years
>>
>>
>>
>> On 10/30/22 4:28 PM, Joe Schaefer wrote:
>> > And to be frank- framing my input as me slagging on Yann is grotesque.
>> You ship GA releases as a team, and so when you ship a dud
>> > like 2.17 you should take your lumps as a team.
>>
>> I admit that the libapreq2 codebase doesn't get that much review
>> attention as other parts of httpd and does not draw that much
>> developer interest. Hence we were very grateful that Yann took some time
>> to do the needful, fixed the security issue and took it
>> to a release to get that issue fixed for the users. Thank you Yann for
>> this. The fact that at least the existing tests still
>> passed after the changes was at least for me a good indicator that the
>> changes don't break stuff and are fine.
>> I also understand if you feel upset if the codebase you wrote and regard
>> as better was changed and if you feel that the code
>> deserves more love and care.
>> The way to fix this is to participate here in a constructive way to get
>> it in the direction you want it to be.
>> If you feel that this isn't the correct community for this codebase we
>> can also talk about this as Eric indicated.
>> I am with Joe Orton and Greg that you are around for long enough to know
>> that the way you started this brought attention to your
>> desires but was counterproductive in many ways (tone of the emails,
>> number of emails, top postings, too broad statements) to get
>> things were you want them to be.
>>
>>
>>
>>
>> Thanks Rüdiger.  I’m not interested in any type of stewardship for this
>> code; my interests have long since moved on.  But my approach to software
>> projects is to finish them, not for them to be perpetual motion machines,
>> so I’m going to be concerned about frequent release cadences and constant
>> churn that entails.
>>
>> I honestly do not expect apreq to be all that burdensome to maintain for
>> you guys, regardless of all of the hot button items being fleshed out by
>> the fact that it’s sitting in your trunk. I think that only helps mature
>> and refine the product, regardless of how you deliver it to users.
>>
>> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

This stuff was written for an RFC era of the mid 2000s, and a lot of the
uncertainties around industry direction have been clarified in the years
since then, particularly as they relate to cookie standards.

The nastiest code in here is the cookie parser logic that was required back
then.  If anything should be radically refactored and simplified, start
there.

On Mon, Oct 31, 2022 at 12:36 PM Joe Schaefer  wrote:

>
>
> Get Outlook for iOS <https://aka.ms/o0ukef>
> --
> *From:* Ruediger Pluem 
> *Sent:* Monday, October 31, 2022 12:21 PM
> *To:* dev@httpd.apache.org 
> *Subject:* Re: [libapreq2] nits to pick about the patches to util.c over
> the past few years
>
>
>
> On 10/30/22 4:28 PM, Joe Schaefer wrote:
> > And to be frank- framing my input as me slagging on Yann is grotesque.
> You ship GA releases as a team, and so when you ship a dud
> > like 2.17 you should take your lumps as a team.
>
> I admit that the libapreq2 codebase doesn't get that much review attention
> as other parts of httpd and does not draw that much
> developer interest. Hence we were very grateful that Yann took some time
> to do the needful, fixed the security issue and took it
> to a release to get that issue fixed for the users. Thank you Yann for
> this. The fact that at least the existing tests still
> passed after the changes was at least for me a good indicator that the
> changes don't break stuff and are fine.
> I also understand if you feel upset if the codebase you wrote and regard
> as better was changed and if you feel that the code
> deserves more love and care.
> The way to fix this is to participate here in a constructive way to get it
> in the direction you want it to be.
> If you feel that this isn't the correct community for this codebase we can
> also talk about this as Eric indicated.
> I am with Joe Orton and Greg that you are around for long enough to know
> that the way you started this brought attention to your
> desires but was counterproductive in many ways (tone of the emails, number
> of emails, top postings, too broad statements) to get
> things were you want them to be.
>
>
>
>
> Thanks Rüdiger.  I’m not interested in any type of stewardship for this
> code; my interests have long since moved on.  But my approach to software
> projects is to finish them, not for them to be perpetual motion machines,
> so I’m going to be concerned about frequent release cadences and constant
> churn that entails.
>
> I honestly do not expect apreq to be all that burdensome to maintain for
> you guys, regardless of all of the hot button items being fleshed out by
> the fact that it’s sitting in your trunk. I think that only helps mature
> and refine the product, regardless of how you deliver it to users.
>
> --
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Ruediger Pluem 
Sent: Monday, October 31, 2022 12:21 PM
To: dev@httpd.apache.org 
Subject: Re: [libapreq2] nits to pick about the patches to util.c over the past 
few years



On 10/30/22 4:28 PM, Joe Schaefer wrote:
> And to be frank- framing my input as me slagging on Yann is grotesque.  You 
> ship GA releases as a team, and so when you ship a dud
> like 2.17 you should take your lumps as a team.

I admit that the libapreq2 codebase doesn't get that much review attention as 
other parts of httpd and does not draw that much
developer interest. Hence we were very grateful that Yann took some time to do 
the needful, fixed the security issue and took it
to a release to get that issue fixed for the users. Thank you Yann for this. 
The fact that at least the existing tests still
passed after the changes was at least for me a good indicator that the changes 
don't break stuff and are fine.
I also understand if you feel upset if the codebase you wrote and regard as 
better was changed and if you feel that the code
deserves more love and care.
The way to fix this is to participate here in a constructive way to get it in 
the direction you want it to be.
If you feel that this isn't the correct community for this codebase we can also 
talk about this as Eric indicated.
I am with Joe Orton and Greg that you are around for long enough to know that 
the way you started this brought attention to your
desires but was counterproductive in many ways (tone of the emails, number of 
emails, top postings, too broad statements) to get
things were you want them to be.




Thanks Rüdiger.  I’m not interested in any type of stewardship for this code; 
my interests have long since moved on.  But my approach to software projects is 
to finish them, not for them to be perpetual motion machines, so I’m going to 
be concerned about frequent release cadences and constant churn that entails.

I honestly do not expect apreq to be all that burdensome to maintain for you 
guys, regardless of all of the hot button items being fleshed out by the fact 
that it’s sitting in your trunk. I think that only helps mature and refine the 
product, regardless of how you deliver it to users.

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

Apologies for the bombast, Joe.

Constructively, I’m just offering development advice as an SME, which you are 
free to act on or not as the team sees fit. But you’re right that this is a 
Releng issue, not a development one, that I’m trying to surface in terms of how 
patch management is happening between HTTPD’s trunk and apreq’s.

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Joe Orton 
Sent: Monday, October 31, 2022 11:07:02 AM
To: dev@httpd.apache.org 
Subject: Re: [libapreq2] nits to pick about the patches to util.c over the past 
few years

On Sun, Oct 30, 2022 at 12:09:02AM -0400, Joe Schaefer wrote:
> Forgive me for summarizing, but I didn’t come here expecting help, much
> less collaboration on a solution.  I came here expecting to be scolded for
> having the temerity to critique the quality of the patch sets you’ve been
> shipping of late In libapreq2.  None of my opinions have changed on that
> subject, and won’t for some time.
>
> The point is I’m part of your extended support channels for libapreq2,
> because it’s easy and fun to help people who use the code.  I’m not here to
> complain, I’m here expecting more empathy for people like me who give their
> time graciously without expecting anything in return other than some
> measure of respect for the effort involved.

Joe, please dial down both the rhetoric and rate of fire.

Constructive criticism is always welcome here, we are quite used to
doing patch reviews. You've come in with a torrent of not very
constructive messages, unsurprisingly that won't get a hugely
sympathetic response from others. We all participate here voluntarily.

Regards, Joe

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

And to be frank- framing my input as me slagging on Yann is grotesque.  You 
ship GA releases as a team, and so when you ship a dud like 2.17 you should 
take your lumps as a team.
Again, you know how to put processes in place to ensure adequate peer review is 
happening, just like you know whimsical patches like the one at fault here do 
not belong in a grave security release that 2.17 was slated to be.

At this point it’s water under the bridge.  Release 2.18, when you see fit, and 
if it’s not insane for us to put it on CPAN, we will.

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Joe Schaefer 
Sent: Sunday, October 30, 2022 12:09:02 AM
To: dev@httpd.apache.org 
Subject: Re: [libapreq2] nits to pick about the patches to util.c over the past 
few years

Forgive me for summarizing, but I didn’t come here expecting help, much less 
collaboration on a solution.  I came here expecting to be scolded for having 
the temerity to critique the quality of the patch sets you’ve been shipping of 
late In libapreq2.  None of my opinions have changed on that subject, and won’t 
for some time.

The point is I’m part of your extended support channels for libapreq2, because 
it’s easy and fun to help people who use the code.  I’m not here to complain, 
I’m here expecting more empathy for people like me who give their time 
graciously without expecting anything in return other than some measure of 
respect for the effort involved.

On Sat, Oct 29, 2022 at 9:59 PM Joe Schaefer 
mailto:j...@sunstarsys.com>> wrote:
Missed one.  The patch that introduced these changes was revision=1895107.



On Sat, Oct 29, 2022 at 9:15 PM Joe Schaefer 
mailto:j...@sunstarsys.com>> wrote:
Of course, I don’t know how to advise you regarding the security aspects, since 
you’re doing what you thought was the right thing to do and put the mfd parser 
into an error state instead of leaving well enough alone.  But basically 
libapreq2 users get annoyed when the parser breaks on valid input, and may get 
antsy when their server goes bonkers because they aren’t in the habit of doing 
error handling on this condition.

On Sat, Oct 29, 2022 at 8:36 PM Joe Schaefer 
mailto:j...@sunstarsys.com>> wrote:
Found the problem: it's just a misunderstanding about what is admissible in a 
successful file upload widget.
If someone doesn't add a file to the upload widget, it is still a successful 
control and should be processed as such on the server.
In this case, just like with opera, the filename attribute will be present, but 
set to an empty double-quoted string.

Here's my patchset, enjoy.









On Sat, Oct 29, 2022 at 2:47 PM Joe Schaefer 
mailto:j...@sunstarsys.com>> wrote:
Curiously, this doesn't seem to present any problems for apreq_header_attribute 
in trunk/HEAD.  A good thing.

That means we may need to look more closely at r1903484 in glue/perl.

On Sat, Oct 29, 2022 at 2:12 PM Joe Schaefer 
mailto:j...@sunstarsys.com>> wrote:

On Sat, Oct 29, 2022 at 1:16 PM Joe Schaefer 
mailto:j...@sunstarsys.com>> wrote:


On Sat, Oct 29, 2022 at 1:00 PM Yann Ylavic 
mailto:ylavic@gmail.com>> wrote:
Hi Joe,

here comes the "goofer".

On Fri, Oct 28, 2022 at 9:05 PM 
mailto:j...@sunstarsys.com>> wrote:
>
> Long time fan, not a first time caller.

Yet what a crappy thread (and comments on [1]).
All top posting, unreplyable.

>
> Libapreq2 was intended to be a safe,fast, standards compliant library- 
> primarily *safe* before all other priorities.  Some of the work going on 
> lately in util.c is starting to undermine that prime directive, so I’d like 
> to better understand why these changes are happening, and why they are 
> snowballing into a less functional, less secure software product that is 
> driving up my support costs on CPAN.

Yeah sure, rewriting history. That marvelous previous 2.16 just
exploded when faced with google's oss-fuzzers (and not just a little,
quite some reports) which now fuzz httpd trunk (thus apreq).
CVE-2022-22728 is about libapreq2 v2.16 *and earlier" right? So
something pre-dated my changes.

Fair enough.


>
> For instance, this revision 1867789 is a pure pessimization:  it trades 
> userland RAM for filesystem cache RAM, that’s it, but it’s not a big deal.  
> Just churn.

I call it a fix for an UAF (Use After Free). This is my only change in
2.16 btw, while you seem to suggest that security issues started with
2.16.

>
> Everything in the crufty, old apreq_header_attribute code I wrote was 
> completely tossed and reimplemented.  Why?

Someone had to address the security reports, and someone (me) dared
touching your code because it was not safe (i.e.
broken/crashing/vulnerable/..), not for the lulz nor breaking users.
I'm very sorry if that happened, only those who do nothing do not
break anything though.
Existing tests were still passing, but shit happens.

Then let

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

Forgive me for summarizing, but I didn’t come here expecting help, much
less collaboration on a solution.  I came here expecting to be scolded for
having the temerity to critique the quality of the patch sets you’ve been
shipping of late In libapreq2.  None of my opinions have changed on that
subject, and won’t for some time.

The point is I’m part of your extended support channels for libapreq2,
because it’s easy and fun to help people who use the code.  I’m not here to
complain, I’m here expecting more empathy for people like me who give their
time graciously without expecting anything in return other than some
measure of respect for the effort involved.

On Sat, Oct 29, 2022 at 9:59 PM Joe Schaefer  wrote:

> Missed one.  The patch that introduced these changes was revision=1895107.
>
>
>
> On Sat, Oct 29, 2022 at 9:15 PM Joe Schaefer  wrote:
>
>> Of course, I don’t know how to advise you regarding the security aspects,
>> since you’re doing what you thought was the right thing to do and put the
>> mfd parser into an error state instead of leaving well enough alone.  But
>> basically libapreq2 users get annoyed when the parser breaks on valid
>> input, and may get antsy when their server goes bonkers because they aren’t
>> in the habit of doing error handling on this condition.
>>
>> On Sat, Oct 29, 2022 at 8:36 PM Joe Schaefer  wrote:
>>
>>> Found the problem: it's just a misunderstanding about what is admissible
>>> in a successful file upload widget.
>>> If someone doesn't add a file to the upload widget, it is still a
>>> successful control and should be processed as such on the server.
>>> In this case, just like with opera, the filename attribute will be
>>> present, but set to an empty double-quoted string.
>>>
>>> Here's my patchset, enjoy.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Oct 29, 2022 at 2:47 PM Joe Schaefer  wrote:
>>>
>>>> Curiously, this doesn't seem to present any problems for
>>>> apreq_header_attribute in trunk/HEAD.  A good thing.
>>>>
>>>> That means we may need to look more closely at r1903484 in glue/perl.
>>>>
>>>> On Sat, Oct 29, 2022 at 2:12 PM Joe Schaefer 
>>>> wrote:
>>>>
>>>>>
>>>>> On Sat, Oct 29, 2022 at 1:16 PM Joe Schaefer 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Oct 29, 2022 at 1:00 PM Yann Ylavic 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Joe,
>>>>>>>
>>>>>>> here comes the "goofer".
>>>>>>>
>>>>>>> On Fri, Oct 28, 2022 at 9:05 PM  wrote:
>>>>>>> >
>>>>>>> > Long time fan, not a first time caller.
>>>>>>>
>>>>>>> Yet what a crappy thread (and comments on [1]).
>>>>>>> All top posting, unreplyable.
>>>>>>>
>>>>>>> >
>>>>>>> > Libapreq2 was intended to be a safe,fast, standards compliant
>>>>>>> library- primarily *safe* before all other priorities.  Some of the work
>>>>>>> going on lately in util.c is starting to undermine that prime 
>>>>>>> directive, so
>>>>>>> I’d like to better understand why these changes are happening, and why 
>>>>>>> they
>>>>>>> are snowballing into a less functional, less secure software product 
>>>>>>> that
>>>>>>> is driving up my support costs on CPAN.
>>>>>>>
>>>>>>> Yeah sure, rewriting history. That marvelous previous 2.16 just
>>>>>>> exploded when faced with google's oss-fuzzers (and not just a little,
>>>>>>> quite some reports) which now fuzz httpd trunk (thus apreq).
>>>>>>> CVE-2022-22728 is about libapreq2 v2.16 *and earlier" right? So
>>>>>>> something pre-dated my changes.
>>>>>>
>>>>>>
>>>>>> Fair enough.
>>>>>>
>>>>>>
>>>>>>>
>>>>>> >
>>>>>>> > For instance, this revision 1867789 is a pure pessimization:  it
>>>>>>> trades userland RAM for filesystem cache RAM, that’s it, but it’s not a 
>>>>>>> big
>>>>>>> deal.  Just churn.
>>&g

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

Missed one.  The patch that introduced these changes was revision=1895107.



On Sat, Oct 29, 2022 at 9:15 PM Joe Schaefer  wrote:

> Of course, I don’t know how to advise you regarding the security aspects,
> since you’re doing what you thought was the right thing to do and put the
> mfd parser into an error state instead of leaving well enough alone.  But
> basically libapreq2 users get annoyed when the parser breaks on valid
> input, and may get antsy when their server goes bonkers because they aren’t
> in the habit of doing error handling on this condition.
>
> On Sat, Oct 29, 2022 at 8:36 PM Joe Schaefer  wrote:
>
>> Found the problem: it's just a misunderstanding about what is admissible
>> in a successful file upload widget.
>> If someone doesn't add a file to the upload widget, it is still a
>> successful control and should be processed as such on the server.
>> In this case, just like with opera, the filename attribute will be
>> present, but set to an empty double-quoted string.
>>
>> Here's my patchset, enjoy.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Oct 29, 2022 at 2:47 PM Joe Schaefer  wrote:
>>
>>> Curiously, this doesn't seem to present any problems for
>>> apreq_header_attribute in trunk/HEAD.  A good thing.
>>>
>>> That means we may need to look more closely at r1903484 in glue/perl.
>>>
>>> On Sat, Oct 29, 2022 at 2:12 PM Joe Schaefer  wrote:
>>>
>>>>
>>>> On Sat, Oct 29, 2022 at 1:16 PM Joe Schaefer 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sat, Oct 29, 2022 at 1:00 PM Yann Ylavic 
>>>>> wrote:
>>>>>
>>>>>> Hi Joe,
>>>>>>
>>>>>> here comes the "goofer".
>>>>>>
>>>>>> On Fri, Oct 28, 2022 at 9:05 PM  wrote:
>>>>>> >
>>>>>> > Long time fan, not a first time caller.
>>>>>>
>>>>>> Yet what a crappy thread (and comments on [1]).
>>>>>> All top posting, unreplyable.
>>>>>>
>>>>>> >
>>>>>> > Libapreq2 was intended to be a safe,fast, standards compliant
>>>>>> library- primarily *safe* before all other priorities.  Some of the work
>>>>>> going on lately in util.c is starting to undermine that prime directive, 
>>>>>> so
>>>>>> I’d like to better understand why these changes are happening, and why 
>>>>>> they
>>>>>> are snowballing into a less functional, less secure software product that
>>>>>> is driving up my support costs on CPAN.
>>>>>>
>>>>>> Yeah sure, rewriting history. That marvelous previous 2.16 just
>>>>>> exploded when faced with google's oss-fuzzers (and not just a little,
>>>>>> quite some reports) which now fuzz httpd trunk (thus apreq).
>>>>>> CVE-2022-22728 is about libapreq2 v2.16 *and earlier" right? So
>>>>>> something pre-dated my changes.
>>>>>
>>>>>
>>>>> Fair enough.
>>>>>
>>>>>
>>>>>>
>>>>> >
>>>>>> > For instance, this revision 1867789 is a pure pessimization:  it
>>>>>> trades userland RAM for filesystem cache RAM, that’s it, but it’s not a 
>>>>>> big
>>>>>> deal.  Just churn.
>>>>>>
>>>>>> I call it a fix for an UAF (Use After Free). This is my only change in
>>>>>> 2.16 btw, while you seem to suggest that security issues started with
>>>>>> 2.16.
>>>>>>
>>>>>> >
>>>>>> > Everything in the crufty, old apreq_header_attribute code I wrote
>>>>>> was completely tossed and reimplemented.  Why?
>>>>>>
>>>>>> Someone had to address the security reports, and someone (me) dared
>>>>>> touching your code because it was not safe (i.e.
>>>>>> broken/crashing/vulnerable/..), not for the lulz nor breaking users.
>>>>>> I'm very sorry if that happened, only those who do nothing do not
>>>>>> break anything though.
>>>>>> Existing tests were still passing, but shit happens.
>>>>>>
>>>>>
>>>>> Then lets deal with it by adding more tests.
>>>>>
>>>>

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

Of course, I don’t know how to advise you regarding the security aspects,
since you’re doing what you thought was the right thing to do and put the
mfd parser into an error state instead of leaving well enough alone.  But
basically libapreq2 users get annoyed when the parser breaks on valid
input, and may get antsy when their server goes bonkers because they aren’t
in the habit of doing error handling on this condition.

On Sat, Oct 29, 2022 at 8:36 PM Joe Schaefer  wrote:

> Found the problem: it's just a misunderstanding about what is admissible
> in a successful file upload widget.
> If someone doesn't add a file to the upload widget, it is still a
> successful control and should be processed as such on the server.
> In this case, just like with opera, the filename attribute will be
> present, but set to an empty double-quoted string.
>
> Here's my patchset, enjoy.
>
>
>
>
>
>
>
>
>
> On Sat, Oct 29, 2022 at 2:47 PM Joe Schaefer  wrote:
>
>> Curiously, this doesn't seem to present any problems for
>> apreq_header_attribute in trunk/HEAD.  A good thing.
>>
>> That means we may need to look more closely at r1903484 in glue/perl.
>>
>> On Sat, Oct 29, 2022 at 2:12 PM Joe Schaefer  wrote:
>>
>>>
>>> On Sat, Oct 29, 2022 at 1:16 PM Joe Schaefer  wrote:
>>>
>>>>
>>>>
>>>> On Sat, Oct 29, 2022 at 1:00 PM Yann Ylavic 
>>>> wrote:
>>>>
>>>>> Hi Joe,
>>>>>
>>>>> here comes the "goofer".
>>>>>
>>>>> On Fri, Oct 28, 2022 at 9:05 PM  wrote:
>>>>> >
>>>>> > Long time fan, not a first time caller.
>>>>>
>>>>> Yet what a crappy thread (and comments on [1]).
>>>>> All top posting, unreplyable.
>>>>>
>>>>> >
>>>>> > Libapreq2 was intended to be a safe,fast, standards compliant
>>>>> library- primarily *safe* before all other priorities.  Some of the work
>>>>> going on lately in util.c is starting to undermine that prime directive, 
>>>>> so
>>>>> I’d like to better understand why these changes are happening, and why 
>>>>> they
>>>>> are snowballing into a less functional, less secure software product that
>>>>> is driving up my support costs on CPAN.
>>>>>
>>>>> Yeah sure, rewriting history. That marvelous previous 2.16 just
>>>>> exploded when faced with google's oss-fuzzers (and not just a little,
>>>>> quite some reports) which now fuzz httpd trunk (thus apreq).
>>>>> CVE-2022-22728 is about libapreq2 v2.16 *and earlier" right? So
>>>>> something pre-dated my changes.
>>>>
>>>>
>>>> Fair enough.
>>>>
>>>>
>>>>>
>>>> >
>>>>> > For instance, this revision 1867789 is a pure pessimization:  it
>>>>> trades userland RAM for filesystem cache RAM, that’s it, but it’s not a 
>>>>> big
>>>>> deal.  Just churn.
>>>>>
>>>>> I call it a fix for an UAF (Use After Free). This is my only change in
>>>>> 2.16 btw, while you seem to suggest that security issues started with
>>>>> 2.16.
>>>>>
>>>>> >
>>>>> > Everything in the crufty, old apreq_header_attribute code I wrote
>>>>> was completely tossed and reimplemented.  Why?
>>>>>
>>>>> Someone had to address the security reports, and someone (me) dared
>>>>> touching your code because it was not safe (i.e.
>>>>> broken/crashing/vulnerable/..), not for the lulz nor breaking users.
>>>>> I'm very sorry if that happened, only those who do nothing do not
>>>>> break anything though.
>>>>> Existing tests were still passing, but shit happens.
>>>>>
>>>>
>>>> Then lets deal with it by adding more tests.
>>>>
>>>>
>>>>>
>>>>> >  We’re just racking up CVE’s, people are disabling the mfd parser
>>>>> altogether, and it no longer support common use cases that people now
>>>>> complain about because it supported cases in the wild that the new work
>>>>> does not.
>>>>>
>>>>> Are there multiple issues? I know of the one reported in [1] about
>>>>> "file upload does not work if any file fields are blank".
>>>>> That's n

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

Found the problem: it's just a misunderstanding about what is admissible in
a successful file upload widget.
If someone doesn't add a file to the upload widget, it is still a
successful control and should be processed as such on the server.
In this case, just like with opera, the filename attribute will be present,
but set to an empty double-quoted string.

Here's my patchset, enjoy.









On Sat, Oct 29, 2022 at 2:47 PM Joe Schaefer  wrote:

> Curiously, this doesn't seem to present any problems for
> apreq_header_attribute in trunk/HEAD.  A good thing.
>
> That means we may need to look more closely at r1903484 in glue/perl.
>
> On Sat, Oct 29, 2022 at 2:12 PM Joe Schaefer  wrote:
>
>>
>> On Sat, Oct 29, 2022 at 1:16 PM Joe Schaefer  wrote:
>>
>>>
>>>
>>> On Sat, Oct 29, 2022 at 1:00 PM Yann Ylavic 
>>> wrote:
>>>
>>>> Hi Joe,
>>>>
>>>> here comes the "goofer".
>>>>
>>>> On Fri, Oct 28, 2022 at 9:05 PM  wrote:
>>>> >
>>>> > Long time fan, not a first time caller.
>>>>
>>>> Yet what a crappy thread (and comments on [1]).
>>>> All top posting, unreplyable.
>>>>
>>>> >
>>>> > Libapreq2 was intended to be a safe,fast, standards compliant
>>>> library- primarily *safe* before all other priorities.  Some of the work
>>>> going on lately in util.c is starting to undermine that prime directive, so
>>>> I’d like to better understand why these changes are happening, and why they
>>>> are snowballing into a less functional, less secure software product that
>>>> is driving up my support costs on CPAN.
>>>>
>>>> Yeah sure, rewriting history. That marvelous previous 2.16 just
>>>> exploded when faced with google's oss-fuzzers (and not just a little,
>>>> quite some reports) which now fuzz httpd trunk (thus apreq).
>>>> CVE-2022-22728 is about libapreq2 v2.16 *and earlier" right? So
>>>> something pre-dated my changes.
>>>
>>>
>>> Fair enough.
>>>
>>>
>>>>
>>> >
>>>> > For instance, this revision 1867789 is a pure pessimization:  it
>>>> trades userland RAM for filesystem cache RAM, that’s it, but it’s not a big
>>>> deal.  Just churn.
>>>>
>>>> I call it a fix for an UAF (Use After Free). This is my only change in
>>>> 2.16 btw, while you seem to suggest that security issues started with
>>>> 2.16.
>>>>
>>>> >
>>>> > Everything in the crufty, old apreq_header_attribute code I wrote was
>>>> completely tossed and reimplemented.  Why?
>>>>
>>>> Someone had to address the security reports, and someone (me) dared
>>>> touching your code because it was not safe (i.e.
>>>> broken/crashing/vulnerable/..), not for the lulz nor breaking users.
>>>> I'm very sorry if that happened, only those who do nothing do not
>>>> break anything though.
>>>> Existing tests were still passing, but shit happens.
>>>>
>>>
>>> Then lets deal with it by adding more tests.
>>>
>>>
>>>>
>>>> >  We’re just racking up CVE’s, people are disabling the mfd parser
>>>> altogether, and it no longer support common use cases that people now
>>>> complain about because it supported cases in the wild that the new work
>>>> does not.
>>>>
>>>> Are there multiple issues? I know of the one reported in [1] about
>>>> "file upload does not work if any file fields are blank".
>>>> That's not actionable sorry (I don't understand what it means), no
>>>> more than your rant here and elusive "hints" on where/how to fix it.
>>>> I asked in the other thread for a reproducer in the form of a HTTP
>>>> payload, not a mod_perl handler which I don't know how to debug (let
>>>> alone without the right thing to send on the client side).
>>>>
>>>>
>>> I translated the bug report for you.  It involves browsers like Opera
>>> that send  filename=""
>>> attributes in the Content-Disposition header.  It's generating an
>>> accidental DoS, depending
>>> on how people use the upload API.  Toss in some tests into util.t and
>>> I'll add this one for you.
>>>
>>>
>>>> >
>>>> > With the latest code coming out of p5p for Perl, there’

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

Curiously, this doesn't seem to present any problems for
apreq_header_attribute in trunk/HEAD.  A good thing.

That means we may need to look more closely at r1903484 in glue/perl.

On Sat, Oct 29, 2022 at 2:12 PM Joe Schaefer  wrote:

>
> On Sat, Oct 29, 2022 at 1:16 PM Joe Schaefer  wrote:
>
>>
>>
>> On Sat, Oct 29, 2022 at 1:00 PM Yann Ylavic  wrote:
>>
>>> Hi Joe,
>>>
>>> here comes the "goofer".
>>>
>>> On Fri, Oct 28, 2022 at 9:05 PM  wrote:
>>> >
>>> > Long time fan, not a first time caller.
>>>
>>> Yet what a crappy thread (and comments on [1]).
>>> All top posting, unreplyable.
>>>
>>> >
>>> > Libapreq2 was intended to be a safe,fast, standards compliant library-
>>> primarily *safe* before all other priorities.  Some of the work going on
>>> lately in util.c is starting to undermine that prime directive, so I’d like
>>> to better understand why these changes are happening, and why they are
>>> snowballing into a less functional, less secure software product that is
>>> driving up my support costs on CPAN.
>>>
>>> Yeah sure, rewriting history. That marvelous previous 2.16 just
>>> exploded when faced with google's oss-fuzzers (and not just a little,
>>> quite some reports) which now fuzz httpd trunk (thus apreq).
>>> CVE-2022-22728 is about libapreq2 v2.16 *and earlier" right? So
>>> something pre-dated my changes.
>>
>>
>> Fair enough.
>>
>>
>>>
>> >
>>> > For instance, this revision 1867789 is a pure pessimization:  it
>>> trades userland RAM for filesystem cache RAM, that’s it, but it’s not a big
>>> deal.  Just churn.
>>>
>>> I call it a fix for an UAF (Use After Free). This is my only change in
>>> 2.16 btw, while you seem to suggest that security issues started with
>>> 2.16.
>>>
>>> >
>>> > Everything in the crufty, old apreq_header_attribute code I wrote was
>>> completely tossed and reimplemented.  Why?
>>>
>>> Someone had to address the security reports, and someone (me) dared
>>> touching your code because it was not safe (i.e.
>>> broken/crashing/vulnerable/..), not for the lulz nor breaking users.
>>> I'm very sorry if that happened, only those who do nothing do not
>>> break anything though.
>>> Existing tests were still passing, but shit happens.
>>>
>>
>> Then lets deal with it by adding more tests.
>>
>>
>>>
>>> >  We’re just racking up CVE’s, people are disabling the mfd parser
>>> altogether, and it no longer support common use cases that people now
>>> complain about because it supported cases in the wild that the new work
>>> does not.
>>>
>>> Are there multiple issues? I know of the one reported in [1] about
>>> "file upload does not work if any file fields are blank".
>>> That's not actionable sorry (I don't understand what it means), no
>>> more than your rant here and elusive "hints" on where/how to fix it.
>>> I asked in the other thread for a reproducer in the form of a HTTP
>>> payload, not a mod_perl handler which I don't know how to debug (let
>>> alone without the right thing to send on the client side).
>>>
>>>
>> I translated the bug report for you.  It involves browsers like Opera
>> that send  filename=""
>> attributes in the Content-Disposition header.  It's generating an
>> accidental DoS, depending
>> on how people use the upload API.  Toss in some tests into util.t and
>> I'll add this one for you.
>>
>>
>>> >
>>> > With the latest code coming out of p5p for Perl, there’s a whole new
>>> reason for excitement in httpd-land: the mod_perl2 + mpm_event combination
>>> is rock solid and screaming fast with HTTP/2.  The only reason I resubbed
>>> here is in the hopes of some synergy retaking these perl-related projects,
>>> since mod_perl2 is the only game in town for embedded interpreters in
>>> httpd2 (and no, lua is not the answer, it’s not thread safe either).
>>>
>>> Synergy! What a great intro..
>>>
>>>
>>> Regards;
>>> Yann.
>>>
>>> [1] https://rt.cpan.org/Public/Bug/Display.html?id=144470
>>>
>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> 
>> 954.253.3732 
>>
>>
>>
>
> Let'

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

On Sat, Oct 29, 2022 at 1:16 PM Joe Schaefer  wrote:

>
>
> On Sat, Oct 29, 2022 at 1:00 PM Yann Ylavic  wrote:
>
>> Hi Joe,
>>
>> here comes the "goofer".
>>
>> On Fri, Oct 28, 2022 at 9:05 PM  wrote:
>> >
>> > Long time fan, not a first time caller.
>>
>> Yet what a crappy thread (and comments on [1]).
>> All top posting, unreplyable.
>>
>> >
>> > Libapreq2 was intended to be a safe,fast, standards compliant library-
>> primarily *safe* before all other priorities.  Some of the work going on
>> lately in util.c is starting to undermine that prime directive, so I’d like
>> to better understand why these changes are happening, and why they are
>> snowballing into a less functional, less secure software product that is
>> driving up my support costs on CPAN.
>>
>> Yeah sure, rewriting history. That marvelous previous 2.16 just
>> exploded when faced with google's oss-fuzzers (and not just a little,
>> quite some reports) which now fuzz httpd trunk (thus apreq).
>> CVE-2022-22728 is about libapreq2 v2.16 *and earlier" right? So
>> something pre-dated my changes.
>
>
> Fair enough.
>
>
>>
> >
>> > For instance, this revision 1867789 is a pure pessimization:  it trades
>> userland RAM for filesystem cache RAM, that’s it, but it’s not a big deal.
>> Just churn.
>>
>> I call it a fix for an UAF (Use After Free). This is my only change in
>> 2.16 btw, while you seem to suggest that security issues started with
>> 2.16.
>>
>> >
>> > Everything in the crufty, old apreq_header_attribute code I wrote was
>> completely tossed and reimplemented.  Why?
>>
>> Someone had to address the security reports, and someone (me) dared
>> touching your code because it was not safe (i.e.
>> broken/crashing/vulnerable/..), not for the lulz nor breaking users.
>> I'm very sorry if that happened, only those who do nothing do not
>> break anything though.
>> Existing tests were still passing, but shit happens.
>>
>
> Then lets deal with it by adding more tests.
>
>
>>
>> >  We’re just racking up CVE’s, people are disabling the mfd parser
>> altogether, and it no longer support common use cases that people now
>> complain about because it supported cases in the wild that the new work
>> does not.
>>
>> Are there multiple issues? I know of the one reported in [1] about
>> "file upload does not work if any file fields are blank".
>> That's not actionable sorry (I don't understand what it means), no
>> more than your rant here and elusive "hints" on where/how to fix it.
>> I asked in the other thread for a reproducer in the form of a HTTP
>> payload, not a mod_perl handler which I don't know how to debug (let
>> alone without the right thing to send on the client side).
>>
>>
> I translated the bug report for you.  It involves browsers like Opera that
> send  filename=""
> attributes in the Content-Disposition header.  It's generating an
> accidental DoS, depending
> on how people use the upload API.  Toss in some tests into util.t and I'll
> add this one for you.
>
>
>> >
>> > With the latest code coming out of p5p for Perl, there’s a whole new
>> reason for excitement in httpd-land: the mod_perl2 + mpm_event combination
>> is rock solid and screaming fast with HTTP/2.  The only reason I resubbed
>> here is in the hopes of some synergy retaking these perl-related projects,
>> since mod_perl2 is the only game in town for embedded interpreters in
>> httpd2 (and no, lua is not the answer, it’s not thread safe either).
>>
>> Synergy! What a great intro..
>>
>>
>> Regards;
>> Yann.
>>
>> [1] https://rt.cpan.org/Public/Bug/Display.html?id=144470
>>
>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

Let's start with this (untested) patch...


Index: library/t/util.c
===
--- library/t/util.c(revision 1904922)
+++ library/t/util.c(working copy)
@@ -271,6 +271,7 @@
 static void test_header_attribute(dAT, void *ctx)
 {
 const char hdr[] = "name=\"filename=foo\"; filename=\"quux.txt\"";
+const char opera[] = "name=\"foo\"; filename=\"\"";
 const char *val;
 apr_size_t vlen;

@@ -284,6 +285,10 @@
 AT_int_eq(vlen, 8);
 AT_mem_eq("quux.txt", val, 8);

+AT_int_eq(apreq_header_attribute(opera, "filename" 8, , ),
+  APR_SUCCESS);
+AT_int_eq(vlen,0);
+
 }

 static void test_brigade_concat(dAT, void *ctx)
@@ -315,7 +320,7 @@
 { dT(test_join, 0) },
 { dT(test_brigade_fwrite, 0) },
 { dT(test_file_mktemp, 0) },
-{ dT(test_header_attribute, 6) },
+{ dT(test_header_attribute, 8) },
 { dT(test_brigade_concat, 0) },
 };
-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

Thanks for the tip! It's actually pretty good news that the only thing
google's fuzzer is complaining about is the very small piece of the puzzle.
We just need to get it right this time.

On Sat, Oct 29, 2022 at 1:38 PM Greg Stein  wrote:

> F/OSS is not about telling others how to write their code, Joe. You know
> this. And it *definitely* is not about demanding they spend *their* time to
> fix your pet issues.
>
> If you have a problem with the code, then supply a fix. Your dozen emails
> are not fixing anything, and are certainly not endearing anybody to help
> you. Be nice, if you want help.
>
> -g
>
>
> On Sat, Oct 29, 2022 at 11:11 AM Joe Schaefer  wrote:
>
>> ...fell apart when Max asked you to release his patch to my screwup with
>> the NPE, and instead of cutting a release
>> with just that patch applied, you began the tragic process of dorking
>> around with apreq_header_attribute() as well.
>>
>> Just pull all those hacks out of apreq/trunk, and release exactly what
>> Max told you to release, and you will be good for another quiet decade of
>> happy libapreq2 users.
>>
>> If you do not take this advice, at least for your own personal
>> reputations, stop hacking the logic and  start writing regression tests.
>>  An internet-grade mfd parser is only as good as its weakest link, and I
>> just spent the past day telling you where that is.
>>
>> On Sat, Oct 29, 2022 at 12:06 PM Joe Schaefer  wrote:
>>
>>> All we need to do at this point is remember the basics of how to cut a
>>> security bugfix release.  Everything in libapreq
>>>
>>> On Fri, Oct 28, 2022 at 3:04 PM  wrote:
>>>
>>>> Long time fan, not a first time caller.
>>>>
>>>>
>>>>
>>>> Libapreq2 was intended to be a safe,fast, standards compliant library-
>>>> primarily **safe** before all other priorities.  Some of the work
>>>> going on lately in util.c is starting to undermine that prime directive, so
>>>> I’d like to better understand why these changes are happening, and why they
>>>> are snowballing into a less functional, less secure software product that
>>>> is driving up my support costs on CPAN.
>>>>
>>>>
>>>>
>>>> For instance, this revision 1867789 is a pure pessimization:  it trades
>>>> userland RAM for filesystem cache RAM, that’s it, but it’s not a big deal.
>>>> Just churn.
>>>>
>>>>
>>>>
>>>> Everything in the crufty, old apreq_header_attribute code I wrote was
>>>> completely tossed and reimplemented.  Why?  We’re just racking up CVE’s,
>>>> people are disabling the mfd parser altogether, and it no longer support
>>>> common use cases that people now complain about because it supported cases
>>>> in the wild that the new work does not.
>>>>
>>>>
>>>>
>>>> With the latest code coming out of p5p for Perl, there’s a whole new
>>>> reason for excitement in httpd-land: the mod_perl2 + mpm_event combination
>>>> is rock solid and screaming fast with HTTP/2.  The only reason I resubbed
>>>> here is in the hopes of some synergy retaking these perl-related projects,
>>>> since mod_perl2 is the only game in town for embedded interpreters in
>>>> httpd2 (and no, lua is not the answer, it’s not thread safe either).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Joe Schaefer, Ph.D.
>>>>
>>>> 
>>>>
>>>> 954.253.3732 
>>>>
>>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>>>> Markdown JAM Stack**™*
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> 
>>> 954.253.3732 
>>>
>>>
>>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> 
>> 954.253.3732 
>>
>>
>>

-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

On Sat, Oct 29, 2022 at 1:00 PM Yann Ylavic  wrote:

> Hi Joe,
>
> here comes the "goofer".
>
> On Fri, Oct 28, 2022 at 9:05 PM  wrote:
> >
> > Long time fan, not a first time caller.
>
> Yet what a crappy thread (and comments on [1]).
> All top posting, unreplyable.
>
> >
> > Libapreq2 was intended to be a safe,fast, standards compliant library-
> primarily *safe* before all other priorities.  Some of the work going on
> lately in util.c is starting to undermine that prime directive, so I’d like
> to better understand why these changes are happening, and why they are
> snowballing into a less functional, less secure software product that is
> driving up my support costs on CPAN.
>
> Yeah sure, rewriting history. That marvelous previous 2.16 just
> exploded when faced with google's oss-fuzzers (and not just a little,
> quite some reports) which now fuzz httpd trunk (thus apreq).
> CVE-2022-22728 is about libapreq2 v2.16 *and earlier" right? So
> something pre-dated my changes.


Fair enough.


>
>
> > For instance, this revision 1867789 is a pure pessimization:  it trades
> userland RAM for filesystem cache RAM, that’s it, but it’s not a big deal.
> Just churn.
>
> I call it a fix for an UAF (Use After Free). This is my only change in
> 2.16 btw, while you seem to suggest that security issues started with
> 2.16.
>
> >
> > Everything in the crufty, old apreq_header_attribute code I wrote was
> completely tossed and reimplemented.  Why?
>
> Someone had to address the security reports, and someone (me) dared
> touching your code because it was not safe (i.e.
> broken/crashing/vulnerable/..), not for the lulz nor breaking users.
> I'm very sorry if that happened, only those who do nothing do not
> break anything though.
> Existing tests were still passing, but shit happens.
>

Then lets deal with it by adding more tests.


>
> >  We’re just racking up CVE’s, people are disabling the mfd parser
> altogether, and it no longer support common use cases that people now
> complain about because it supported cases in the wild that the new work
> does not.
>
> Are there multiple issues? I know of the one reported in [1] about
> "file upload does not work if any file fields are blank".
> That's not actionable sorry (I don't understand what it means), no
> more than your rant here and elusive "hints" on where/how to fix it.
> I asked in the other thread for a reproducer in the form of a HTTP
> payload, not a mod_perl handler which I don't know how to debug (let
> alone without the right thing to send on the client side).
>
>
I translated the bug report for you.  It involves browsers like Opera that
send  filename=""
attributes in the Content-Disposition header.  It's generating an
accidental DoS, depending
on how people use the upload API.  Toss in some tests into util.t and I'll
add this one for you.


> >
> > With the latest code coming out of p5p for Perl, there’s a whole new
> reason for excitement in httpd-land: the mod_perl2 + mpm_event combination
> is rock solid and screaming fast with HTTP/2.  The only reason I resubbed
> here is in the hopes of some synergy retaking these perl-related projects,
> since mod_perl2 is the only game in town for embedded interpreters in
> httpd2 (and no, lua is not the answer, it’s not thread safe either).
>
> Synergy! What a great intro..
>
>
> Regards;
> Yann.
>
> [1] https://rt.cpan.org/Public/Bug/Display.html?id=144470
>


-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

...fell apart when Max asked you to release his patch to my screwup with
the NPE, and instead of cutting a release
with just that patch applied, you began the tragic process of dorking
around with apreq_header_attribute() as well.

Just pull all those hacks out of apreq/trunk, and release exactly what Max
told you to release, and you will be good for another quiet decade of happy
libapreq2 users.

If you do not take this advice, at least for your own personal reputations,
stop hacking the logic and  start writing regression tests.
 An internet-grade mfd parser is only as good as its weakest link, and I
just spent the past day telling you where that is.

On Sat, Oct 29, 2022 at 12:06 PM Joe Schaefer  wrote:

> All we need to do at this point is remember the basics of how to cut a
> security bugfix release.  Everything in libapreq
>
> On Fri, Oct 28, 2022 at 3:04 PM  wrote:
>
>> Long time fan, not a first time caller.
>>
>>
>>
>> Libapreq2 was intended to be a safe,fast, standards compliant library-
>> primarily **safe** before all other priorities.  Some of the work going
>> on lately in util.c is starting to undermine that prime directive, so I’d
>> like to better understand why these changes are happening, and why they are
>> snowballing into a less functional, less secure software product that is
>> driving up my support costs on CPAN.
>>
>>
>>
>> For instance, this revision 1867789 is a pure pessimization:  it trades
>> userland RAM for filesystem cache RAM, that’s it, but it’s not a big deal.
>> Just churn.
>>
>>
>>
>> Everything in the crufty, old apreq_header_attribute code I wrote was
>> completely tossed and reimplemented.  Why?  We’re just racking up CVE’s,
>> people are disabling the mfd parser altogether, and it no longer support
>> common use cases that people now complain about because it supported cases
>> in the wild that the new work does not.
>>
>>
>>
>> With the latest code coming out of p5p for Perl, there’s a whole new
>> reason for excitement in httpd-land: the mod_perl2 + mpm_event combination
>> is rock solid and screaming fast with HTTP/2.  The only reason I resubbed
>> here is in the hopes of some synergy retaking these perl-related projects,
>> since mod_perl2 is the only game in town for embedded interpreters in
>> httpd2 (and no, lua is not the answer, it’s not thread safe either).
>>
>>
>>
>>
>>
>> Joe Schaefer, Ph.D.
>>
>> 
>>
>> 954.253.3732 
>>
>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>> Markdown JAM Stack**™*
>>
>>
>>
>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

All we need to do at this point is remember the basics of how to cut a
security bugfix release.  Everything in libapreq

On Fri, Oct 28, 2022 at 3:04 PM  wrote:

> Long time fan, not a first time caller.
>
>
>
> Libapreq2 was intended to be a safe,fast, standards compliant library-
> primarily **safe** before all other priorities.  Some of the work going
> on lately in util.c is starting to undermine that prime directive, so I’d
> like to better understand why these changes are happening, and why they are
> snowballing into a less functional, less secure software product that is
> driving up my support costs on CPAN.
>
>
>
> For instance, this revision 1867789 is a pure pessimization:  it trades
> userland RAM for filesystem cache RAM, that’s it, but it’s not a big deal.
> Just churn.
>
>
>
> Everything in the crufty, old apreq_header_attribute code I wrote was
> completely tossed and reimplemented.  Why?  We’re just racking up CVE’s,
> people are disabling the mfd parser altogether, and it no longer support
> common use cases that people now complain about because it supported cases
> in the wild that the new work does not.
>
>
>
> With the latest code coming out of p5p for Perl, there’s a whole new
> reason for excitement in httpd-land: the mod_perl2 + mpm_event combination
> is rock solid and screaming fast with HTTP/2.  The only reason I resubbed
> here is in the hopes of some synergy retaking these perl-related projects,
> since mod_perl2 is the only game in town for embedded interpreters in
> httpd2 (and no, lua is not the answer, it’s not thread safe either).
>
>
>
>
>
> Joe Schaefer, Ph.D.
>
> 
>
> 954.253.3732 
>
> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
> Markdown JAM Stack**™*
>
>
>


-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

At least a DoS grade CVE, depending on how users call into the upload API
(server hangs).  Are we having a sufficient amount of fun dorking with
util.c in libapreq2 production?

On Fri, Oct 28, 2022 at 8:59 PM Joe Schaefer  wrote:

> There’s likely another CVE to add to the matrix revolving around the way
> the current code deals with an empty file name attribute, given the bizarre
> behavior of the rest of the code that runs after.
>
> On Fri, Oct 28, 2022 at 6:56 PM Joe Schaefer  wrote:
>
>> There simply is no usable libapreq2 release that's not either riddled
>> with CVE's, or actually supports every common browser that submits
>> form-data online.
>> That wasn't apreq developer's doing, it was httpd's.  All you've been
>> doing is pushing alpha quality apreq_header_attribute implementations that
>> you wouldn't dream of shipping in httpd3 GA,
>> and letting libapreq users be your QA department instead of writing tests
>> to demonstrate your bona-fides to tackle this problem appropriately in any
>> GA software project.
>> There's a lot of ways of handling the discrepancy between the code in
>> httpd/trunk and the code in apreq/trunk (our release branch) that doesn't
>> involve this nonsense.
>>
>> You can do better, because I've seen it.  All anyone can ask is for
>> better QA in GA releases in a project that has only seen one dud after the
>> next for three plus years.
>> It will make httpd3 better in the future if you do.
>>
>> On Fri, Oct 28, 2022 at 5:39 PM Joe Schaefer  wrote:
>>
>>> You first.  I'm just an old fart mining the CPAN show for you. I told
>>> you what you need to fix the bug, let's see some bugfixing.
>>>
>>> On Fri, Oct 28, 2022 at 5:24 PM Eric Covener  wrote:
>>>
>>>> If it's the same issue as the one Steve brought up on the 2.17 release
>>>> vote thread, please add something constructive (like a test) there.
>>>>
>>>> On Fri, Oct 28, 2022 at 5:15 PM Joe Schaefer 
>>>> wrote:
>>>>
>>>>> The Unit Test infra already exists in the apreq tree.  Just add tests
>>>>> to the test files that are already present.
>>>>> If it's a pain in the ass to do this with Apache::Test, that's
>>>>> irrelevant to the point I'm making.  We don't use Apache::Test for testing
>>>>> libapreq2.so
>>>>>
>>>>> On Fri, Oct 28, 2022 at 5:00 PM Joe Schaefer 
>>>>> wrote:
>>>>>
>>>>>> We don't need to be friends to get along Eric.  We just need httpd to
>>>>>> test your code with unit and regression tests before you release it to 
>>>>>> the
>>>>>> rest of the planet.  After all, it's what we used to do when we cared 
>>>>>> about
>>>>>> CVE's with parsers.
>>>>>>
>>>>>> On Fri, Oct 28, 2022 at 4:51 PM Joe Schaefer 
>>>>>> wrote:
>>>>>>
>>>>>>> Hell no.  But there are consequences to treating the project as a
>>>>>>> guinea pig for httpd.
>>>>>>>
>>>>>>> On Fri, Oct 28, 2022 at 4:50 PM Eric Covener 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Would you like to maintain it outside of httpd?
>>>>>>>>
>>>>>>>> my +1 to drop the subproject and rip it from httpd trunk.
>>>>>>>>
>>>>>>>> On Fri, Oct 28, 2022 at 3:51 PM Joe Schaefer 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> The function under scrutiny here is apreq_header_attribute. The
>>>>>>>>> only use case for that function in a form-data
>>>>>>>>> parsing library is to deal with the Content-Disposition header,
>>>>>>>>> which has a very tight MIME spec that does not
>>>>>>>>> involve rewriting the old code for a generic header attribute
>>>>>>>>> parser, without anyone filing a bug report about the
>>>>>>>>> original one.
>>>>>>>>>
>>>>>>>>> libapreq2 is an old, stable codebase. The Perl community likes it
>>>>>>>>> that way. We think it's great when flaws are discovered,
>>>>>>>>> which means patches are in order.  But it is not the right
>>>>>>>>> codebase for sloppy experiments with unusable logic over something
&

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

There’s likely another CVE to add to the matrix revolving around the way
the current code deals with an empty file name attribute, given the bizarre
behavior of the rest of the code that runs after.

On Fri, Oct 28, 2022 at 6:56 PM Joe Schaefer  wrote:

> There simply is no usable libapreq2 release that's not either riddled with
> CVE's, or actually supports every common browser that submits form-data
> online.
> That wasn't apreq developer's doing, it was httpd's.  All you've been
> doing is pushing alpha quality apreq_header_attribute implementations that
> you wouldn't dream of shipping in httpd3 GA,
> and letting libapreq users be your QA department instead of writing tests
> to demonstrate your bona-fides to tackle this problem appropriately in any
> GA software project.
> There's a lot of ways of handling the discrepancy between the code in
> httpd/trunk and the code in apreq/trunk (our release branch) that doesn't
> involve this nonsense.
>
> You can do better, because I've seen it.  All anyone can ask is for better
> QA in GA releases in a project that has only seen one dud after the next
> for three plus years.
> It will make httpd3 better in the future if you do.
>
> On Fri, Oct 28, 2022 at 5:39 PM Joe Schaefer  wrote:
>
>> You first.  I'm just an old fart mining the CPAN show for you. I told you
>> what you need to fix the bug, let's see some bugfixing.
>>
>> On Fri, Oct 28, 2022 at 5:24 PM Eric Covener  wrote:
>>
>>> If it's the same issue as the one Steve brought up on the 2.17 release
>>> vote thread, please add something constructive (like a test) there.
>>>
>>> On Fri, Oct 28, 2022 at 5:15 PM Joe Schaefer  wrote:
>>>
>>>> The Unit Test infra already exists in the apreq tree.  Just add tests
>>>> to the test files that are already present.
>>>> If it's a pain in the ass to do this with Apache::Test, that's
>>>> irrelevant to the point I'm making.  We don't use Apache::Test for testing
>>>> libapreq2.so
>>>>
>>>> On Fri, Oct 28, 2022 at 5:00 PM Joe Schaefer 
>>>> wrote:
>>>>
>>>>> We don't need to be friends to get along Eric.  We just need httpd to
>>>>> test your code with unit and regression tests before you release it to the
>>>>> rest of the planet.  After all, it's what we used to do when we cared 
>>>>> about
>>>>> CVE's with parsers.
>>>>>
>>>>> On Fri, Oct 28, 2022 at 4:51 PM Joe Schaefer 
>>>>> wrote:
>>>>>
>>>>>> Hell no.  But there are consequences to treating the project as a
>>>>>> guinea pig for httpd.
>>>>>>
>>>>>> On Fri, Oct 28, 2022 at 4:50 PM Eric Covener 
>>>>>> wrote:
>>>>>>
>>>>>>> Would you like to maintain it outside of httpd?
>>>>>>>
>>>>>>> my +1 to drop the subproject and rip it from httpd trunk.
>>>>>>>
>>>>>>> On Fri, Oct 28, 2022 at 3:51 PM Joe Schaefer 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> The function under scrutiny here is apreq_header_attribute. The
>>>>>>>> only use case for that function in a form-data
>>>>>>>> parsing library is to deal with the Content-Disposition header,
>>>>>>>> which has a very tight MIME spec that does not
>>>>>>>> involve rewriting the old code for a generic header attribute
>>>>>>>> parser, without anyone filing a bug report about the
>>>>>>>> original one.
>>>>>>>>
>>>>>>>> libapreq2 is an old, stable codebase. The Perl community likes it
>>>>>>>> that way. We think it's great when flaws are discovered,
>>>>>>>> which means patches are in order.  But it is not the right codebase
>>>>>>>> for sloppy experiments with unusable logic over something
>>>>>>>> that does the job and has had no discoverable buffer overflows,
>>>>>>>> ever.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Oct 28, 2022 at 3:17 PM Joe Schaefer 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> None of the patches to util.c include corresponding patches to any
>>>>>>>>> of the several layers of test suites involved in libapreq.
>>>>>>>>> It'

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

There simply is no usable libapreq2 release that's not either riddled with
CVE's, or actually supports every common browser that submits form-data
online.
That wasn't apreq developer's doing, it was httpd's.  All you've been doing
is pushing alpha quality apreq_header_attribute implementations that you
wouldn't dream of shipping in httpd3 GA,
and letting libapreq users be your QA department instead of writing tests
to demonstrate your bona-fides to tackle this problem appropriately in any
GA software project.
There's a lot of ways of handling the discrepancy between the code in
httpd/trunk and the code in apreq/trunk (our release branch) that doesn't
involve this nonsense.

You can do better, because I've seen it.  All anyone can ask is for better
QA in GA releases in a project that has only seen one dud after the next
for three plus years.
It will make httpd3 better in the future if you do.

On Fri, Oct 28, 2022 at 5:39 PM Joe Schaefer  wrote:

> You first.  I'm just an old fart mining the CPAN show for you. I told you
> what you need to fix the bug, let's see some bugfixing.
>
> On Fri, Oct 28, 2022 at 5:24 PM Eric Covener  wrote:
>
>> If it's the same issue as the one Steve brought up on the 2.17 release
>> vote thread, please add something constructive (like a test) there.
>>
>> On Fri, Oct 28, 2022 at 5:15 PM Joe Schaefer  wrote:
>>
>>> The Unit Test infra already exists in the apreq tree.  Just add tests to
>>> the test files that are already present.
>>> If it's a pain in the ass to do this with Apache::Test, that's
>>> irrelevant to the point I'm making.  We don't use Apache::Test for testing
>>> libapreq2.so
>>>
>>> On Fri, Oct 28, 2022 at 5:00 PM Joe Schaefer  wrote:
>>>
>>>> We don't need to be friends to get along Eric.  We just need httpd to
>>>> test your code with unit and regression tests before you release it to the
>>>> rest of the planet.  After all, it's what we used to do when we cared about
>>>> CVE's with parsers.
>>>>
>>>> On Fri, Oct 28, 2022 at 4:51 PM Joe Schaefer 
>>>> wrote:
>>>>
>>>>> Hell no.  But there are consequences to treating the project as a
>>>>> guinea pig for httpd.
>>>>>
>>>>> On Fri, Oct 28, 2022 at 4:50 PM Eric Covener 
>>>>> wrote:
>>>>>
>>>>>> Would you like to maintain it outside of httpd?
>>>>>>
>>>>>> my +1 to drop the subproject and rip it from httpd trunk.
>>>>>>
>>>>>> On Fri, Oct 28, 2022 at 3:51 PM Joe Schaefer 
>>>>>> wrote:
>>>>>>
>>>>>>> The function under scrutiny here is apreq_header_attribute. The only
>>>>>>> use case for that function in a form-data
>>>>>>> parsing library is to deal with the Content-Disposition header,
>>>>>>> which has a very tight MIME spec that does not
>>>>>>> involve rewriting the old code for a generic header attribute
>>>>>>> parser, without anyone filing a bug report about the
>>>>>>> original one.
>>>>>>>
>>>>>>> libapreq2 is an old, stable codebase. The Perl community likes it
>>>>>>> that way. We think it's great when flaws are discovered,
>>>>>>> which means patches are in order.  But it is not the right codebase
>>>>>>> for sloppy experiments with unusable logic over something
>>>>>>> that does the job and has had no discoverable buffer overflows, ever.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 28, 2022 at 3:17 PM Joe Schaefer 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> None of the patches to util.c include corresponding patches to any
>>>>>>>> of the several layers of test suites involved in libapreq.
>>>>>>>> It's starting to wear on our user's nerves.
>>>>>>>>
>>>>>>>> On Fri, Oct 28, 2022 at 3:04 PM  wrote:
>>>>>>>>
>>>>>>>>> Long time fan, not a first time caller.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Libapreq2 was intended to be a safe,fast, standards compliant
>>>>>>>>> library- primarily **safe** before all other priorities.  Some of
>>>>>>>>> the work going on lately in util.c is starting to undermine 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

You first.  I'm just an old fart mining the CPAN show for you. I told you
what you need to fix the bug, let's see some bugfixing.

On Fri, Oct 28, 2022 at 5:24 PM Eric Covener  wrote:

> If it's the same issue as the one Steve brought up on the 2.17 release
> vote thread, please add something constructive (like a test) there.
>
> On Fri, Oct 28, 2022 at 5:15 PM Joe Schaefer  wrote:
>
>> The Unit Test infra already exists in the apreq tree.  Just add tests to
>> the test files that are already present.
>> If it's a pain in the ass to do this with Apache::Test, that's irrelevant
>> to the point I'm making.  We don't use Apache::Test for testing libapreq2.so
>>
>> On Fri, Oct 28, 2022 at 5:00 PM Joe Schaefer  wrote:
>>
>>> We don't need to be friends to get along Eric.  We just need httpd to
>>> test your code with unit and regression tests before you release it to the
>>> rest of the planet.  After all, it's what we used to do when we cared about
>>> CVE's with parsers.
>>>
>>> On Fri, Oct 28, 2022 at 4:51 PM Joe Schaefer  wrote:
>>>
>>>> Hell no.  But there are consequences to treating the project as a
>>>> guinea pig for httpd.
>>>>
>>>> On Fri, Oct 28, 2022 at 4:50 PM Eric Covener  wrote:
>>>>
>>>>> Would you like to maintain it outside of httpd?
>>>>>
>>>>> my +1 to drop the subproject and rip it from httpd trunk.
>>>>>
>>>>> On Fri, Oct 28, 2022 at 3:51 PM Joe Schaefer 
>>>>> wrote:
>>>>>
>>>>>> The function under scrutiny here is apreq_header_attribute. The only
>>>>>> use case for that function in a form-data
>>>>>> parsing library is to deal with the Content-Disposition header,
>>>>>> which has a very tight MIME spec that does not
>>>>>> involve rewriting the old code for a generic header attribute parser,
>>>>>> without anyone filing a bug report about the
>>>>>> original one.
>>>>>>
>>>>>> libapreq2 is an old, stable codebase. The Perl community likes it
>>>>>> that way. We think it's great when flaws are discovered,
>>>>>> which means patches are in order.  But it is not the right codebase
>>>>>> for sloppy experiments with unusable logic over something
>>>>>> that does the job and has had no discoverable buffer overflows, ever.
>>>>>>
>>>>>>
>>>>>> On Fri, Oct 28, 2022 at 3:17 PM Joe Schaefer 
>>>>>> wrote:
>>>>>>
>>>>>>> None of the patches to util.c include corresponding patches to any
>>>>>>> of the several layers of test suites involved in libapreq.
>>>>>>> It's starting to wear on our user's nerves.
>>>>>>>
>>>>>>> On Fri, Oct 28, 2022 at 3:04 PM  wrote:
>>>>>>>
>>>>>>>> Long time fan, not a first time caller.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Libapreq2 was intended to be a safe,fast, standards compliant
>>>>>>>> library- primarily **safe** before all other priorities.  Some of
>>>>>>>> the work going on lately in util.c is starting to undermine that prime
>>>>>>>> directive, so I’d like to better understand why these changes are
>>>>>>>> happening, and why they are snowballing into a less functional, less 
>>>>>>>> secure
>>>>>>>> software product that is driving up my support costs on CPAN.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> For instance, this revision 1867789 is a pure pessimization:  it
>>>>>>>> trades userland RAM for filesystem cache RAM, that’s it, but it’s not 
>>>>>>>> a big
>>>>>>>> deal.  Just churn.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Everything in the crufty, old apreq_header_attribute code I wrote
>>>>>>>> was completely tossed and reimplemented.  Why?  We’re just racking up
>>>>>>>> CVE’s, people are disabling the mfd parser altogether, and it no longer
>>>>>>>> support common use cases that people now complain about because it
>>&

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

Just take this patch:
https://svn.apache.org/viewvc/httpd/apreq/trunk/library/t/util.c?r1=1124517=1903497=1903497

and put a lot more labor into the edge cases and malformed headers that you
already know trigger RCE.  It's a good start,
yay, but needs more than just confirmation that the usual inputs work.

Lately, security-conscious browsers that send *empty* filename
attributes are choking it, according to CPAN bugs.

I'd be happy to write a test for that one for you, if the team puts more
interest in sounding out this code in a meaningful way
(ie unit and regresssion tests in the apreq tree) that plays into your
current needs for this functionality going forward.



On Fri, Oct 28, 2022 at 5:15 PM Joe Schaefer  wrote:

> The Unit Test infra already exists in the apreq tree.  Just add tests to
> the test files that are already present.
> If it's a pain in the ass to do this with Apache::Test, that's irrelevant
> to the point I'm making.  We don't use Apache::Test for testing libapreq2.so
>
> On Fri, Oct 28, 2022 at 5:00 PM Joe Schaefer  wrote:
>
>> We don't need to be friends to get along Eric.  We just need httpd to
>> test your code with unit and regression tests before you release it to the
>> rest of the planet.  After all, it's what we used to do when we cared about
>> CVE's with parsers.
>>
>> On Fri, Oct 28, 2022 at 4:51 PM Joe Schaefer  wrote:
>>
>>> Hell no.  But there are consequences to treating the project as a guinea
>>> pig for httpd.
>>>
>>> On Fri, Oct 28, 2022 at 4:50 PM Eric Covener  wrote:
>>>
>>>> Would you like to maintain it outside of httpd?
>>>>
>>>> my +1 to drop the subproject and rip it from httpd trunk.
>>>>
>>>> On Fri, Oct 28, 2022 at 3:51 PM Joe Schaefer 
>>>> wrote:
>>>>
>>>>> The function under scrutiny here is apreq_header_attribute. The only
>>>>> use case for that function in a form-data
>>>>> parsing library is to deal with the Content-Disposition header,
>>>>> which has a very tight MIME spec that does not
>>>>> involve rewriting the old code for a generic header attribute parser,
>>>>> without anyone filing a bug report about the
>>>>> original one.
>>>>>
>>>>> libapreq2 is an old, stable codebase. The Perl community likes it that
>>>>> way. We think it's great when flaws are discovered,
>>>>> which means patches are in order.  But it is not the right codebase
>>>>> for sloppy experiments with unusable logic over something
>>>>> that does the job and has had no discoverable buffer overflows, ever.
>>>>>
>>>>>
>>>>> On Fri, Oct 28, 2022 at 3:17 PM Joe Schaefer 
>>>>> wrote:
>>>>>
>>>>>> None of the patches to util.c include corresponding patches to any of
>>>>>> the several layers of test suites involved in libapreq.
>>>>>> It's starting to wear on our user's nerves.
>>>>>>
>>>>>> On Fri, Oct 28, 2022 at 3:04 PM  wrote:
>>>>>>
>>>>>>> Long time fan, not a first time caller.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Libapreq2 was intended to be a safe,fast, standards compliant
>>>>>>> library- primarily **safe** before all other priorities.  Some of
>>>>>>> the work going on lately in util.c is starting to undermine that prime
>>>>>>> directive, so I’d like to better understand why these changes are
>>>>>>> happening, and why they are snowballing into a less functional, less 
>>>>>>> secure
>>>>>>> software product that is driving up my support costs on CPAN.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> For instance, this revision 1867789 is a pure pessimization:  it
>>>>>>> trades userland RAM for filesystem cache RAM, that’s it, but it’s not a 
>>>>>>> big
>>>>>>> deal.  Just churn.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Everything in the crufty, old apreq_header_attribute code I wrote
>>>>>>> was completely tossed and reimplemented.  Why?  We’re just racking up
>>>>>>> CVE’s, people are disabling the mfd parser altogether, and it no longer
>>>>>>> support common use cases that people now complain about because it
&g

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

The Unit Test infra already exists in the apreq tree.  Just add tests to
the test files that are already present.
If it's a pain in the ass to do this with Apache::Test, that's irrelevant
to the point I'm making.  We don't use Apache::Test for testing libapreq2.so

On Fri, Oct 28, 2022 at 5:00 PM Joe Schaefer  wrote:

> We don't need to be friends to get along Eric.  We just need httpd to test
> your code with unit and regression tests before you release it to the rest
> of the planet.  After all, it's what we used to do when we cared about
> CVE's with parsers.
>
> On Fri, Oct 28, 2022 at 4:51 PM Joe Schaefer  wrote:
>
>> Hell no.  But there are consequences to treating the project as a guinea
>> pig for httpd.
>>
>> On Fri, Oct 28, 2022 at 4:50 PM Eric Covener  wrote:
>>
>>> Would you like to maintain it outside of httpd?
>>>
>>> my +1 to drop the subproject and rip it from httpd trunk.
>>>
>>> On Fri, Oct 28, 2022 at 3:51 PM Joe Schaefer  wrote:
>>>
>>>> The function under scrutiny here is apreq_header_attribute. The only
>>>> use case for that function in a form-data
>>>> parsing library is to deal with the Content-Disposition header,
>>>> which has a very tight MIME spec that does not
>>>> involve rewriting the old code for a generic header attribute parser,
>>>> without anyone filing a bug report about the
>>>> original one.
>>>>
>>>> libapreq2 is an old, stable codebase. The Perl community likes it that
>>>> way. We think it's great when flaws are discovered,
>>>> which means patches are in order.  But it is not the right codebase for
>>>> sloppy experiments with unusable logic over something
>>>> that does the job and has had no discoverable buffer overflows, ever.
>>>>
>>>>
>>>> On Fri, Oct 28, 2022 at 3:17 PM Joe Schaefer 
>>>> wrote:
>>>>
>>>>> None of the patches to util.c include corresponding patches to any of
>>>>> the several layers of test suites involved in libapreq.
>>>>> It's starting to wear on our user's nerves.
>>>>>
>>>>> On Fri, Oct 28, 2022 at 3:04 PM  wrote:
>>>>>
>>>>>> Long time fan, not a first time caller.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Libapreq2 was intended to be a safe,fast, standards compliant
>>>>>> library- primarily **safe** before all other priorities.  Some of
>>>>>> the work going on lately in util.c is starting to undermine that prime
>>>>>> directive, so I’d like to better understand why these changes are
>>>>>> happening, and why they are snowballing into a less functional, less 
>>>>>> secure
>>>>>> software product that is driving up my support costs on CPAN.
>>>>>>
>>>>>>
>>>>>>
>>>>>> For instance, this revision 1867789 is a pure pessimization:  it
>>>>>> trades userland RAM for filesystem cache RAM, that’s it, but it’s not a 
>>>>>> big
>>>>>> deal.  Just churn.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Everything in the crufty, old apreq_header_attribute code I wrote was
>>>>>> completely tossed and reimplemented.  Why?  We’re just racking up CVE’s,
>>>>>> people are disabling the mfd parser altogether, and it no longer support
>>>>>> common use cases that people now complain about because it supported 
>>>>>> cases
>>>>>> in the wild that the new work does not.
>>>>>>
>>>>>>
>>>>>>
>>>>>> With the latest code coming out of p5p for Perl, there’s a whole new
>>>>>> reason for excitement in httpd-land: the mod_perl2 + mpm_event 
>>>>>> combination
>>>>>> is rock solid and screaming fast with HTTP/2.  The only reason I resubbed
>>>>>> here is in the hopes of some synergy retaking these perl-related 
>>>>>> projects,
>>>>>> since mod_perl2 is the only game in town for embedded interpreters in
>>>>>> httpd2 (and no, lua is not the answer, it’s not thread safe either).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Joe Schaefer, Ph.D.
>>>>>>
>>>>>> 
>>>>>>
>>>>>> 954.253.3732 
>>>>>>
>>>>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>>>>>> Markdown JAM Stack**™*
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Joe Schaefer, Ph.D.
>>>>> We only build what you need built.
>>>>> 
>>>>> 954.253.3732 
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Joe Schaefer, Ph.D.
>>>> We only build what you need built.
>>>> 
>>>> 954.253.3732 
>>>>
>>>>
>>>>
>>>
>>> --
>>> Eric Covener
>>> cove...@gmail.com
>>>
>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> 
>> 954.253.3732 
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

We don't need to be friends to get along Eric.  We just need httpd to test
your code with unit and regression tests before you release it to the rest
of the planet.  After all, it's what we used to do when we cared about
CVE's with parsers.

On Fri, Oct 28, 2022 at 4:51 PM Joe Schaefer  wrote:

> Hell no.  But there are consequences to treating the project as a guinea
> pig for httpd.
>
> On Fri, Oct 28, 2022 at 4:50 PM Eric Covener  wrote:
>
>> Would you like to maintain it outside of httpd?
>>
>> my +1 to drop the subproject and rip it from httpd trunk.
>>
>> On Fri, Oct 28, 2022 at 3:51 PM Joe Schaefer  wrote:
>>
>>> The function under scrutiny here is apreq_header_attribute. The only use
>>> case for that function in a form-data
>>> parsing library is to deal with the Content-Disposition header,
>>> which has a very tight MIME spec that does not
>>> involve rewriting the old code for a generic header attribute parser,
>>> without anyone filing a bug report about the
>>> original one.
>>>
>>> libapreq2 is an old, stable codebase. The Perl community likes it that
>>> way. We think it's great when flaws are discovered,
>>> which means patches are in order.  But it is not the right codebase for
>>> sloppy experiments with unusable logic over something
>>> that does the job and has had no discoverable buffer overflows, ever.
>>>
>>>
>>> On Fri, Oct 28, 2022 at 3:17 PM Joe Schaefer  wrote:
>>>
>>>> None of the patches to util.c include corresponding patches to any of
>>>> the several layers of test suites involved in libapreq.
>>>> It's starting to wear on our user's nerves.
>>>>
>>>> On Fri, Oct 28, 2022 at 3:04 PM  wrote:
>>>>
>>>>> Long time fan, not a first time caller.
>>>>>
>>>>>
>>>>>
>>>>> Libapreq2 was intended to be a safe,fast, standards compliant library-
>>>>> primarily **safe** before all other priorities.  Some of the work
>>>>> going on lately in util.c is starting to undermine that prime directive, 
>>>>> so
>>>>> I’d like to better understand why these changes are happening, and why 
>>>>> they
>>>>> are snowballing into a less functional, less secure software product that
>>>>> is driving up my support costs on CPAN.
>>>>>
>>>>>
>>>>>
>>>>> For instance, this revision 1867789 is a pure pessimization:  it
>>>>> trades userland RAM for filesystem cache RAM, that’s it, but it’s not a 
>>>>> big
>>>>> deal.  Just churn.
>>>>>
>>>>>
>>>>>
>>>>> Everything in the crufty, old apreq_header_attribute code I wrote was
>>>>> completely tossed and reimplemented.  Why?  We’re just racking up CVE’s,
>>>>> people are disabling the mfd parser altogether, and it no longer support
>>>>> common use cases that people now complain about because it supported cases
>>>>> in the wild that the new work does not.
>>>>>
>>>>>
>>>>>
>>>>> With the latest code coming out of p5p for Perl, there’s a whole new
>>>>> reason for excitement in httpd-land: the mod_perl2 + mpm_event combination
>>>>> is rock solid and screaming fast with HTTP/2.  The only reason I resubbed
>>>>> here is in the hopes of some synergy retaking these perl-related projects,
>>>>> since mod_perl2 is the only game in town for embedded interpreters in
>>>>> httpd2 (and no, lua is not the answer, it’s not thread safe either).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Joe Schaefer, Ph.D.
>>>>>
>>>>> 
>>>>>
>>>>> 954.253.3732 
>>>>>
>>>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>>>>> Markdown JAM Stack**™*
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Joe Schaefer, Ph.D.
>>>> We only build what you need built.
>>>> 
>>>> 954.253.3732 
>>>>
>>>>
>>>>
>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> 
>>> 954.253.3732 
>>>
>>>
>>>
>>
>> --
>> Eric Covener
>> cove...@gmail.com
>>
>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

Hell no.  But there are consequences to treating the project as a guinea
pig for httpd.

On Fri, Oct 28, 2022 at 4:50 PM Eric Covener  wrote:

> Would you like to maintain it outside of httpd?
>
> my +1 to drop the subproject and rip it from httpd trunk.
>
> On Fri, Oct 28, 2022 at 3:51 PM Joe Schaefer  wrote:
>
>> The function under scrutiny here is apreq_header_attribute. The only use
>> case for that function in a form-data
>> parsing library is to deal with the Content-Disposition header, which has
>> a very tight MIME spec that does not
>> involve rewriting the old code for a generic header attribute parser,
>> without anyone filing a bug report about the
>> original one.
>>
>> libapreq2 is an old, stable codebase. The Perl community likes it that
>> way. We think it's great when flaws are discovered,
>> which means patches are in order.  But it is not the right codebase for
>> sloppy experiments with unusable logic over something
>> that does the job and has had no discoverable buffer overflows, ever.
>>
>>
>> On Fri, Oct 28, 2022 at 3:17 PM Joe Schaefer  wrote:
>>
>>> None of the patches to util.c include corresponding patches to any of
>>> the several layers of test suites involved in libapreq.
>>> It's starting to wear on our user's nerves.
>>>
>>> On Fri, Oct 28, 2022 at 3:04 PM  wrote:
>>>
>>>> Long time fan, not a first time caller.
>>>>
>>>>
>>>>
>>>> Libapreq2 was intended to be a safe,fast, standards compliant library-
>>>> primarily **safe** before all other priorities.  Some of the work
>>>> going on lately in util.c is starting to undermine that prime directive, so
>>>> I’d like to better understand why these changes are happening, and why they
>>>> are snowballing into a less functional, less secure software product that
>>>> is driving up my support costs on CPAN.
>>>>
>>>>
>>>>
>>>> For instance, this revision 1867789 is a pure pessimization:  it trades
>>>> userland RAM for filesystem cache RAM, that’s it, but it’s not a big deal.
>>>> Just churn.
>>>>
>>>>
>>>>
>>>> Everything in the crufty, old apreq_header_attribute code I wrote was
>>>> completely tossed and reimplemented.  Why?  We’re just racking up CVE’s,
>>>> people are disabling the mfd parser altogether, and it no longer support
>>>> common use cases that people now complain about because it supported cases
>>>> in the wild that the new work does not.
>>>>
>>>>
>>>>
>>>> With the latest code coming out of p5p for Perl, there’s a whole new
>>>> reason for excitement in httpd-land: the mod_perl2 + mpm_event combination
>>>> is rock solid and screaming fast with HTTP/2.  The only reason I resubbed
>>>> here is in the hopes of some synergy retaking these perl-related projects,
>>>> since mod_perl2 is the only game in town for embedded interpreters in
>>>> httpd2 (and no, lua is not the answer, it’s not thread safe either).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Joe Schaefer, Ph.D.
>>>>
>>>> 
>>>>
>>>> 954.253.3732 
>>>>
>>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>>>> Markdown JAM Stack**™*
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> 
>>> 954.253.3732 
>>>
>>>
>>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> 
>> 954.253.3732 
>>
>>
>>
>
> --
> Eric Covener
> cove...@gmail.com
>


-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

The good news is that I haven't seen this much buzz about apreq in the CPAN
bug tracker in 15 years, so take the groaning with a grain of salt.


On Fri, Oct 28, 2022 at 4:06 PM Joe Schaefer  wrote:

> What I'd like to see happen is util.c reverted back to 532620.  The
> current HEAD is unusable for many users, who are now stuck with the choice
> of rolling back to the 2.16 release and accepting the buffer overflows that
> come with it.
>
>
>
> On Fri, Oct 28, 2022 at 3:51 PM Joe Schaefer  wrote:
>
>> The function under scrutiny here is apreq_header_attribute. The only use
>> case for that function in a form-data
>> parsing library is to deal with the Content-Disposition header, which has
>> a very tight MIME spec that does not
>> involve rewriting the old code for a generic header attribute parser,
>> without anyone filing a bug report about the
>> original one.
>>
>> libapreq2 is an old, stable codebase. The Perl community likes it that
>> way. We think it's great when flaws are discovered,
>> which means patches are in order.  But it is not the right codebase for
>> sloppy experiments with unusable logic over something
>> that does the job and has had no discoverable buffer overflows, ever.
>>
>>
>> On Fri, Oct 28, 2022 at 3:17 PM Joe Schaefer  wrote:
>>
>>> None of the patches to util.c include corresponding patches to any of
>>> the several layers of test suites involved in libapreq.
>>> It's starting to wear on our user's nerves.
>>>
>>> On Fri, Oct 28, 2022 at 3:04 PM  wrote:
>>>
>>>> Long time fan, not a first time caller.
>>>>
>>>>
>>>>
>>>> Libapreq2 was intended to be a safe,fast, standards compliant library-
>>>> primarily **safe** before all other priorities.  Some of the work
>>>> going on lately in util.c is starting to undermine that prime directive, so
>>>> I’d like to better understand why these changes are happening, and why they
>>>> are snowballing into a less functional, less secure software product that
>>>> is driving up my support costs on CPAN.
>>>>
>>>>
>>>>
>>>> For instance, this revision 1867789 is a pure pessimization:  it trades
>>>> userland RAM for filesystem cache RAM, that’s it, but it’s not a big deal.
>>>> Just churn.
>>>>
>>>>
>>>>
>>>> Everything in the crufty, old apreq_header_attribute code I wrote was
>>>> completely tossed and reimplemented.  Why?  We’re just racking up CVE’s,
>>>> people are disabling the mfd parser altogether, and it no longer support
>>>> common use cases that people now complain about because it supported cases
>>>> in the wild that the new work does not.
>>>>
>>>>
>>>>
>>>> With the latest code coming out of p5p for Perl, there’s a whole new
>>>> reason for excitement in httpd-land: the mod_perl2 + mpm_event combination
>>>> is rock solid and screaming fast with HTTP/2.  The only reason I resubbed
>>>> here is in the hopes of some synergy retaking these perl-related projects,
>>>> since mod_perl2 is the only game in town for embedded interpreters in
>>>> httpd2 (and no, lua is not the answer, it’s not thread safe either).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Joe Schaefer, Ph.D.
>>>>
>>>> 
>>>>
>>>> 954.253.3732 
>>>>
>>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>>>> Markdown JAM Stack**™*
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> 
>>> 954.253.3732 
>>>
>>>
>>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> 
>> 954.253.3732 
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

What I'd like to see happen is util.c reverted back to 532620.  The current
HEAD is unusable for many users, who are now stuck with the choice of
rolling back to the 2.16 release and accepting the buffer overflows that
come with it.



On Fri, Oct 28, 2022 at 3:51 PM Joe Schaefer  wrote:

> The function under scrutiny here is apreq_header_attribute. The only use
> case for that function in a form-data
> parsing library is to deal with the Content-Disposition header, which has
> a very tight MIME spec that does not
> involve rewriting the old code for a generic header attribute parser,
> without anyone filing a bug report about the
> original one.
>
> libapreq2 is an old, stable codebase. The Perl community likes it that
> way. We think it's great when flaws are discovered,
> which means patches are in order.  But it is not the right codebase for
> sloppy experiments with unusable logic over something
> that does the job and has had no discoverable buffer overflows, ever.
>
>
> On Fri, Oct 28, 2022 at 3:17 PM Joe Schaefer  wrote:
>
>> None of the patches to util.c include corresponding patches to any of the
>> several layers of test suites involved in libapreq.
>> It's starting to wear on our user's nerves.
>>
>> On Fri, Oct 28, 2022 at 3:04 PM  wrote:
>>
>>> Long time fan, not a first time caller.
>>>
>>>
>>>
>>> Libapreq2 was intended to be a safe,fast, standards compliant library-
>>> primarily **safe** before all other priorities.  Some of the work going
>>> on lately in util.c is starting to undermine that prime directive, so I’d
>>> like to better understand why these changes are happening, and why they are
>>> snowballing into a less functional, less secure software product that is
>>> driving up my support costs on CPAN.
>>>
>>>
>>>
>>> For instance, this revision 1867789 is a pure pessimization:  it trades
>>> userland RAM for filesystem cache RAM, that’s it, but it’s not a big deal.
>>> Just churn.
>>>
>>>
>>>
>>> Everything in the crufty, old apreq_header_attribute code I wrote was
>>> completely tossed and reimplemented.  Why?  We’re just racking up CVE’s,
>>> people are disabling the mfd parser altogether, and it no longer support
>>> common use cases that people now complain about because it supported cases
>>> in the wild that the new work does not.
>>>
>>>
>>>
>>> With the latest code coming out of p5p for Perl, there’s a whole new
>>> reason for excitement in httpd-land: the mod_perl2 + mpm_event combination
>>> is rock solid and screaming fast with HTTP/2.  The only reason I resubbed
>>> here is in the hopes of some synergy retaking these perl-related projects,
>>> since mod_perl2 is the only game in town for embedded interpreters in
>>> httpd2 (and no, lua is not the answer, it’s not thread safe either).
>>>
>>>
>>>
>>>
>>>
>>> Joe Schaefer, Ph.D.
>>>
>>> 
>>>
>>> 954.253.3732 
>>>
>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>>> Markdown JAM Stack**™*
>>>
>>>
>>>
>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> 
>> 954.253.3732 
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

The function under scrutiny here is apreq_header_attribute. The only use
case for that function in a form-data
parsing library is to deal with the Content-Disposition header, which has a
very tight MIME spec that does not
involve rewriting the old code for a generic header attribute parser,
without anyone filing a bug report about the
original one.

libapreq2 is an old, stable codebase. The Perl community likes it that way.
We think it's great when flaws are discovered,
which means patches are in order.  But it is not the right codebase for
sloppy experiments with unusable logic over something
that does the job and has had no discoverable buffer overflows, ever.


On Fri, Oct 28, 2022 at 3:17 PM Joe Schaefer  wrote:

> None of the patches to util.c include corresponding patches to any of the
> several layers of test suites involved in libapreq.
> It's starting to wear on our user's nerves.
>
> On Fri, Oct 28, 2022 at 3:04 PM  wrote:
>
>> Long time fan, not a first time caller.
>>
>>
>>
>> Libapreq2 was intended to be a safe,fast, standards compliant library-
>> primarily **safe** before all other priorities.  Some of the work going
>> on lately in util.c is starting to undermine that prime directive, so I’d
>> like to better understand why these changes are happening, and why they are
>> snowballing into a less functional, less secure software product that is
>> driving up my support costs on CPAN.
>>
>>
>>
>> For instance, this revision 1867789 is a pure pessimization:  it trades
>> userland RAM for filesystem cache RAM, that’s it, but it’s not a big deal.
>> Just churn.
>>
>>
>>
>> Everything in the crufty, old apreq_header_attribute code I wrote was
>> completely tossed and reimplemented.  Why?  We’re just racking up CVE’s,
>> people are disabling the mfd parser altogether, and it no longer support
>> common use cases that people now complain about because it supported cases
>> in the wild that the new work does not.
>>
>>
>>
>> With the latest code coming out of p5p for Perl, there’s a whole new
>> reason for excitement in httpd-land: the mod_perl2 + mpm_event combination
>> is rock solid and screaming fast with HTTP/2.  The only reason I resubbed
>> here is in the hopes of some synergy retaking these perl-related projects,
>> since mod_perl2 is the only game in town for embedded interpreters in
>> httpd2 (and no, lua is not the answer, it’s not thread safe either).
>>
>>
>>
>>
>>
>> Joe Schaefer, Ph.D.
>>
>> 
>>
>> 954.253.3732 
>>
>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>> Markdown JAM Stack**™*
>>
>>
>>
>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

None of the patches to util.c include corresponding patches to any of the
several layers of test suites involved in libapreq.
It's starting to wear on our user's nerves.

On Fri, Oct 28, 2022 at 3:04 PM  wrote:

> Long time fan, not a first time caller.
>
>
>
> Libapreq2 was intended to be a safe,fast, standards compliant library-
> primarily **safe** before all other priorities.  Some of the work going
> on lately in util.c is starting to undermine that prime directive, so I’d
> like to better understand why these changes are happening, and why they are
> snowballing into a less functional, less secure software product that is
> driving up my support costs on CPAN.
>
>
>
> For instance, this revision 1867789 is a pure pessimization:  it trades
> userland RAM for filesystem cache RAM, that’s it, but it’s not a big deal.
> Just churn.
>
>
>
> Everything in the crufty, old apreq_header_attribute code I wrote was
> completely tossed and reimplemented.  Why?  We’re just racking up CVE’s,
> people are disabling the mfd parser altogether, and it no longer support
> common use cases that people now complain about because it supported cases
> in the wild that the new work does not.
>
>
>
> With the latest code coming out of p5p for Perl, there’s a whole new
> reason for excitement in httpd-land: the mod_perl2 + mpm_event combination
> is rock solid and screaming fast with HTTP/2.  The only reason I resubbed
> here is in the hopes of some synergy retaking these perl-related projects,
> since mod_perl2 is the only game in town for embedded interpreters in
> httpd2 (and no, lua is not the answer, it’s not thread safe either).
>
>
>
>
>
> Joe Schaefer, Ph.D.
>
> 
>
> 954.253.3732 
>
> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
> Markdown JAM Stack**™*
>
>
>


-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: Was there any concrete decision on apreq?

[Joe Schaefer]

apreq is really both Graham, a httpd module and a library.But what I'd like to 
see is the apreq stuff in the server'score put into a separate library and have 
either httpd orthe apreq module link to it.
Unfortunately the existing build system for apreq is automakebased, and I don't 
have much knowledge right now about howto build a dll from httpd's build 
system.  Other people do obviously,I mean apr does it, it's just not something 
I immediately grok.
 

 On Sunday, March 8, 2015 11:48 AM, Graham Leggett minf...@sharp.fm wrote:
   

 On 08 Mar 2015, at 9:11 AM, Joseph Schaefer joe_schae...@yahoo.com wrote:

 In a nutshell the long term goal has always been to get the c parts of apreq 
 incorporated into httpd distributions so the perl parts can ship with 
 modperl.  This is still along those lines.  In order to continue to expose 
 the cool cgi code that Issac added to libapreq we need to ensure there is an 
 actual external library still when we ship with httpd otherwise we lose the 
 modular features we spent so much time designing as apreq would then be 
 limited to httpd modules only.  I'd like to see it serve the entire gamut of 
 web apps including fast cgi.  That's what my ongoing plans are for the httpd 
 project.

+1.

For ages library functions for httpd have ended up in APR, but this isn’t ideal 
- APR is a portability layer, and even though code is being accepted that 
“works with APR”, in reality we really need a libhttpd library that can provide 
“web server like stuff” in a proper true library form. Will certainly make 
tools in the “support” area of the httpd tree easier to develop for, as none of 
the tools have access to httpd proper, and code must be cut and pasted.

I don’t like that apreq as a loadable module, but I would love it as a proper 
shared library.

Same with the expressions code.

Regards,
Graham
—


   

Re: [VOTE] Release httpd 2.2.27 as GA?

[Joe Schaefer]

What is the specific issue Bill- afaict everything looks fine to me.



 On Wednesday, March 26, 2014 6:17 PM, William A. Rowe Jr. 
 wr...@rowe-clan.net wrote:
  On Mon, 17 Mar 2014 05:40:19 -0500
 William A. Rowe Jr. wmr...@gmail.com wrote:
 
  I've been running behind too... But expect to have all my platforms
  checked out Monday.  Since there are no negative votes we'll keep
  this open a bit longer.
 
 Apologies for the delay, this has been pushed to the live site.
 
 Many thanks to rjung for the apr fixes already in 1.5.x branch which had
 confounded me (I noted the changes discussed here, and didn't look over
 for his earlier fixes).  
 
 I cannot figure out what is going on with my attempt to refresh the
 http://httpd.apache.org/security/vulnerabilities_22.html page with the
 two new CVE's... if anyone can cast light on this, I'd much appreciate
 the guidance.

Re: chunked trailers input filter processing by ap_http_filter should be documented

[Joe Schaefer]

Thx Bill!  I will let a few days of lazy consensus
pass before committing this to trunk.






 From: William A. Rowe Jr. wr...@rowe-clan.net
To: dev@httpd.apache.org 
Cc: joe_schae...@yahoo.com 
Sent: Tuesday, February 12, 2013 11:52 AM
Subject: Re: chunked trailers input filter processing by ap_http_filter should 
be documented
 
On Sun, 10 Feb 2013 08:25:35 -0800 (PST)
Joe Schaefer joe_schae...@yahoo.com wrote:

 Here's a sledgehammer patch to ap_rgetline_core()
 to replace r-input_filters with r-proto_input_filters.
 This would still mean protocol filters behind ap_http_filter
 would need to punt on these calls, but that's a lot
 more reasonable than imposing it on AP_FTYPE_RESOURCE
 and similar filters as well.

+1, seems much saner.  Request filters have no business reading
beyond end of request body.

INSERT_BEFORE logic backwards on input filters

[Joe Schaefer]

Here is the INSERT_BEFORE macro in util_filter.c:

#define INSERT_BEFORE(f, before_this) ((before_this) == NULL \

   || (before_this)-frec-ftype  (f)-frec-ftype \
   || (before_this)-r != (f)-r)


While it does the right thing for output filters, for
input filters it's broken: the ftype check should be =


(before_this)-frec-ftype = (f)-frec-ftype

The reason this sucks now is because whenever I have to develop
input filter code where more than one addition of a filter
is involved, the current code screws up the chronological ordering
of how the filters get added- it puts newer additions further past
older ones up the chain, which I always have to fix with some crufty
filter relocation code.


I don't know how to easily patch this because most of the filtering
logic is based around doing the same thing for output filters and
input filters, but this pain has been around for a long time now
and I don't know if anyone has raised the issue before.

chunked trailers input filter processing by ap_http_filter should be documented

[Joe Schaefer]

So ap_http_filter winds up calling ap_get_mime_headers
once it recognizes that the request body has finished,
to process the trailing headers on chunked requests.
This is actually a strange thing to do, because it means
ap_http_filter winds up calling ap_get_brigade on
r-input_filters with AP_MODE_GETLINE set, right in the middle of an
existing ap_get_brigade sequence on the filter chain.
In other words, this recursion only works if all
post-protocol filters are written to punt on processing
AP_MODE_GETLINE invocations- this is what we need to
document somewhere if we don't want to fix the code.

It would be logically better if there were a way to pass a
ap_filter_t argument to ap_get_mime_headers so ap_http_filter
didn't need to reach backwards in the input filter chain just
to finish its HTTP protocol handling.

Re: chunked trailers input filter processing by ap_http_filter should be documented

[Joe Schaefer]

Here's a sledgehammer patch to ap_rgetline_core()
to replace r-input_filters with r-proto_input_filters.
This would still mean protocol filters behind ap_http_filter
would need to punt on these calls, but that's a lot
more reasonable than imposing it on AP_FTYPE_RESOURCE
and similar filters as well.



Index: protocol.c
===
--- protocol.c    (revision 1331861)
+++ protocol.c    (working copy)
@@ -229,7 +229,7 @@
 
 for (;;) {
 apr_brigade_cleanup(bb);
-    rv = ap_get_brigade(r-input_filters, bb, AP_MODE_GETLINE,
+    rv = ap_get_brigade(r-proto_input_filters, bb, AP_MODE_GETLINE,
 APR_BLOCK_READ, 0);
 if (rv != APR_SUCCESS) {
 return rv;
@@ -346,7 +346,7 @@
 apr_brigade_cleanup(bb);
 
 /* We only care about the first byte. */
-    rv = ap_get_brigade(r-input_filters, bb, AP_MODE_SPECULATIVE,
+    rv = ap_get_brigade(r-proto_input_filters, bb, 
AP_MODE_SPECULATIVE,
 APR_BLOCK_READ, 1);
 if (rv != APR_SUCCESS) {
 return rv;








 From: Joe Schaefer joe_schae...@yahoo.com
To: dev@httpd.apache.org dev@httpd.apache.org 
Sent: Sunday, February 10, 2013 11:05 AM
Subject: chunked trailers input filter processing by ap_http_filter should be 
documented
 

So ap_http_filter winds up calling ap_get_mime_headers
once it recognizes that the request body has finished,
to process the trailing headers on chunked requests.
This is actually a strange thing to do, because it means
ap_http_filter winds up calling ap_get_brigade on
r-input_filters with AP_MODE_GETLINE set, right in the middle of an
existing ap_get_brigade sequence on the filter chain.
In other words, this recursion only works if all
post-protocol filters are written to punt on processing
AP_MODE_GETLINE invocations- this is what we need to
document somewhere if we don't want to fix the code.


It would be logically better if there were a way to pass a
ap_filter_t argument to ap_get_mime_headers so ap_http_filter
didn't need to reach backwards in the input filter chain just
to finish its HTTP protocol handling.

Re: [VOTE] Adopt the comments.a.o system to the 2.2 and 2.4 branch of the httpd docs

[Joe Schaefer]

+1!



- Original Message -
 From: Daniel Gruno rum...@cord.dk
 To: dev@httpd.apache.org; d...@httpd.apache.org
 Cc: 
 Sent: Sunday, July 8, 2012 6:22 PM
 Subject: Re: [VOTE] Adopt the comments.a.o system to the 2.2 and 2.4 branch 
 of the httpd docs
 
 On 07/08/2012 10:33 PM, Daniel Gruno wrote:
 
  [X] +1: Adopt the comments.a.o system in the 2.2 and 2.4 branch of docs
  [ ]  0: I don't care
  [ ] -1: Don't adopt the system, because
 
 
 Forgot to cast my own vote - so there.

Re: Empty cookies [Was Re: libapreq2 co-maintainer]

[Joe Schaefer]

apreq does the right thing now by both throwing an
exception (indicating a malformed cookie) and parsing
the header correctly.  This is a very old subject:
Thomas should be using eval like so:

   $apreq = APR::Request::Apache2-handle($r);
   my $jar = eval { $apreq-jar };
   $jar = $@-jar if $@;
   ...

IOW not a bug, please don't fix.



- Original Message -
 From: Issac Goldstand mar...@beamartyr.net
 To: j...@apache.org
 Cc: Thomas Busch tbu...@cpan.org; apreq-dev@httpd.apache.org
 Sent: Thursday, June 21, 2012 2:19 PM
 Subject: Empty cookies [Was Re: libapreq2 co-maintainer]
 
 On 20/06/2012 14:19, Thomas Busch wrote:
  On 20/06/2012 13:35, Thomas Busch wrote:
  The reason I'm asking is that the following bug
 
  https://rt.cpan.org/Public/Bug/Display.html?id=69866
 
  hasn't been solved and is still causing Internal Server 
 Error's on
  a lot of mod_perl installation.
 
  I see you've got a suggested patch there, so there's a good 
 chance that
  someone will pick that up - if noone does it by the weekend, I'll 
 try to
  pick it up myself.
 
 
 Joe, you seemingly addressed this in r748782 and then intentionally put
 it back in r748790 - you touched the exact test case which would deal
 with the a cookie that looked like Cookie: foo=bar;foo2=test;blabla. 
 
 Any recollections of why you put it back?
 
   Issac

Re: [PATCH] mod_log_forensic security considerations

[Joe Schaefer]

- Original Message -

 From: Daniel Gruno rum...@cord.dk
 To: dev@httpd.apache.org
 Cc: 
 Sent: Friday, June 8, 2012 6:24 AM
 Subject: Re: [PATCH] mod_log_forensic security considerations
 
 On 06/08/2012 12:13 PM, Graham Leggett wrote:
  On 08 Jun 2012, at 12:16 AM, Daniel Ruggeri wrote:
 
  I share Williams concern that this makes mod_forensic potentially 
 less 
  useful.
 
  Maybe making the forensic log mode 600 by default would be a better 
 
  idea?
  Agreed as well. This module isn't enabled by default and is most 
 likely
  to be enabled by a user that knows what they are trying to accomplish.
  To me, a clear and concise security warning in the documentation should
  be all that is needed.
 
  IMO, having unadulterated logging capability is what makes
  mod_dumpio/mod_log_forensic some of the most useful modules for
  troubleshooting in a proxy/crashing scenario (respectively).
  +1.
 
  Regards,
  Graham
  --
 
 +1 to that. We already have the same kind of warnings in place for
 people setting up proxies, I see no reason why we can't do the same to
 mod_log_forensic.
 The module is, as the name says, for forensic logging, so it should be
 expected that as much as possible is logged by default, and any special
 considerations should be something you could change, but it shouldn't be
 the default behaviour to not include this and that because it may be
 potentially unsafe. We got bit by it, yes, but that was because we made
 the logs available to people, and that's what we should warn about if
 anything.

Well not quite, we'd still have had a problem with storing and archiving
those logs even if we hadn't made them available to committers, because
they violate our password retention policies.


 
 With regards,
 Daniel.
 

Re: [PATCH] mod_log_forensic security considerations

[Joe Schaefer]

For several years Graham those logs were rather valuable
in tracking down segfaulting svn requests.  Security releases
were made as a result of some of those reports to the 

Subversion project.



- Original Message -
 From: Graham Leggett minf...@sharp.fm
 To: dev@httpd.apache.org
 Cc: 
 Sent: Friday, June 8, 2012 12:51 PM
 Subject: Re: [PATCH] mod_log_forensic security considerations
 
 On 08 Jun 2012, at 5:45 PM, Joe Schaefer wrote:
 
  Well not quite, we'd still have had a problem with storing and 
 archiving
  those logs even if we hadn't made them available to committers, because
  they violate our password retention policies.
 
 Can you clarify if possible what purpose you were trying to solve by enabling 
 the forensic logs?
 
 Forensic logging is to answer the question what is going wrong, and 
 shouldn't be enabled under normal operational circumstances unless there is 
 something genuinely going wrong, at which point you record what you need and 
 then switch it off again.
 
 A forensic log that has had a whole lot of filters applied to it is 
 counterproductive, because the forensic log no longer tells you exactly what 
 is 
 going on, and when you're troubleshooting you need to know precisely that.
 
 Regards,
 Graham
 --

Re: [PATCH] mod_log_forensic security considerations

[Joe Schaefer]

Session cookies sometimes pose a security risk as well.



- Original Message -
 From: Jeff Trawick traw...@gmail.com
 To: d...@httpd.apache.org; dev@httpd.apache.org
 Cc: 
 Sent: Wednesday, June 6, 2012 3:46 PM
 Subject: Re: [PATCH] mod_log_forensic security considerations
 
 On Tue, May 29, 2012 at 1:36 PM, Daniel Shahaf d...@daniel.shahaf.name 
 wrote:
  https://blogs.apache.org/infra/entry/apache_org_incident_report_for
 
  Infra got bit by mod_log_forensic logs including Authorization headers
  and being world-readable, so in an effort to save someone else from
  repeating this mistake how about adding it to the Security
  considerations section of the documentation:
 
  [[[
  Index: docs/manual/mod/mod_log_forensic.xml
  ===
  --- docs/manual/mod/mod_log_forensic.xml        (revision 1342688)
  +++ docs/manual/mod/mod_log_forensic.xml        (working copy)
  @@ -93,6 +93,10 @@
      document for details on why your security could be compromised
      if the directory where logfiles are stored is writable by
      anyone other than the user that starts the server./p
  +    pThe logfiles may contain sensitive data such as the contents 
 of
  +    codeAuthorization:/code headers (which can contain 
 passwords), so
  +    they should not be readable by anyone except the user that starts the
  +    server./p
   /section
 
   directivesynopsis
  ]]]
 
  Perhaps it would be a useful feature to allow excluding those headers
  from being logged, too.
 
 IMO they shouldn't be logged by default (if at all).
 Proxy-Authorization also needs to be handled.  (Anything else?  My
 search query foo is particularly bad today.)
 
 Attached is a potential code fix...  I guess a directive could be
 added to allow them to be logged, but when would that be needed?  (A.
 When the request crashes due to the exact value of one of these
 headers and the module author needs it for debugging.)
 
 -- 
 Born in Roswell... married an alien...
 http://emptyhammock.com/
 
 
 -
 To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org
 For additional commands, e-mail: docs-h...@httpd.apache.org

Re: svn commit: r1341930 - /httpd/httpd/trunk/docs/manual/suexec.html.en

[Joe Schaefer]

This won't happen once the docs are migrated to the CMS ;-)



- Original Message -
 From: Joe Orton jor...@redhat.com
 To: dev@httpd.apache.org
 Cc: 
 Sent: Wednesday, May 23, 2012 6:30 PM
 Subject: Re: svn commit: r1341930 - 
 /httpd/httpd/trunk/docs/manual/suexec.html.en
 
 On Thu, May 24, 2012 at 12:22:43AM +0200, André Malo wrote:
  * jor...@apache.org wrote:
 
   Author: jorton
   Date: Wed May 23 16:06:02 2012
   New Revision: 1341930
  
   URL: http://svn.apache.org/viewvc?rev=1341930view=rev
   Log:
   * docs/manual/suexec.html.en: Update for syslog logging.
 
  Duh. Am I missing something here or didn't you update the XML file?
 
 Oops, sorry, I'm losing it.  Done in r1342078!

[RESULTS] Re: [VOTE] CMS site migration

[Joe Schaefer]

Tally ho!  We have a winnah in the +1's:

+1: pctony, rbowen, joes, igalic, rpluem, minfrin, humbedooh.

 0: jimjag, trawick

-1:

As such the vote passes and I'll do the deed
sometime later today.  The trunk/README has already
been updated Graham, now time to remove all that
java fun.





 From: Joe Schaefer joe_schae...@yahoo.com
To: dev@httpd.apache.org dev@httpd.apache.org 
Cc: d...@httpd.apache.org d...@httpd.apache.org 
Sent: Tuesday, May 8, 2012 3:14 PM
Subject: [VOTE] CMS site migration
 
Please cast your vote accordingly:

[ ] : +1 to migrate httpd-site to the CMS
[ ] :  0 don't care one way or the other
[ ] : -1 leave httpd-site as-is, because...

Note: this vote is only for httpd-site, not
any of the externals (eg the docs trees) that are pulled in.

T-72 hours before the results are tallied.
Voting rules are majority-consensus, same
as for releases.

Re: svn commit: r817280 - /websites/production/httpd/content/

[Joe Schaefer]

Sort of- I forgot httpd has it's own vhost with a mountain
of legacy garbage that needed pruning first.



- Original Message -
 From: Jeff Trawick traw...@gmail.com
 To: dev@httpd.apache.org
 Cc: 
 Sent: Friday, May 11, 2012 4:43 PM
 Subject: Re: svn commit: r817280 - /websites/production/httpd/content/
 
 On Fri, May 11, 2012 at 3:59 PM,  j...@apache.org wrote:
  Author: joes
  Date: Fri May 11 19:59:56 2012
  New Revision: 817280
 
  Log:
  Publishing svnmucc operation to httpd site by joes
 
 By chance would the timing window ending with this commit explain this
 symptom someone just reported to another list?
 
 Just noticed that http://httpd.apache.org is serving a directory index of 
 /content/.
 
 
  Added:
     websites/production/httpd/content/
       - copied from r817279, websites/staging/httpd/trunk/content/
 
 
 
 
 -- 
 Born in Roswell... married an alien...
 http://emptyhammock.com/

Re: [VOTE] CMS site migration

[Joe Schaefer]

The only significant workflow change is thatinstead of building
the docs you will need to publish them,either via the CMS site
or through the http://s.apache.org/cms-cliscript.

Nevertheless I'll update the README file in trunk with the full
details.



- Original Message -
 From: Graham Leggett minf...@sharp.fm
 To: dev@httpd.apache.org
 Cc: d...@httpd.apache.org d...@httpd.apache.org
 Sent: Wednesday, May 9, 2012 6:06 AM
 Subject: Re: [VOTE] CMS site migration
 
 On 08 May 2012, at 9:14 PM, Joe Schaefer wrote:
 
  Please cast your vote accordingly:
 
  [X] : +1 to migrate httpd-site to the CMS
 
 This is however with the condition that the process to update the CMS is 
 properly documented, and all stale documentation relating to the old way of 
 doing things is removed, so there is no chance for confusion.
 
 Regards,
 Graham
 --
 

Re: [VOTE] CMS site migration

[Joe Schaefer]

Damned Y! loves to munge whitespace.  The link is

http://s.apache.org/cms-cli



- Original Message -
 From: Joe Schaefer joe_schae...@yahoo.com
 To: d...@httpd.apache.org d...@httpd.apache.org; dev@httpd.apache.org 
 dev@httpd.apache.org
 Cc: 
 Sent: Wednesday, May 9, 2012 6:34 AM
 Subject: Re: [VOTE] CMS site migration
 
T he only significant workflow change is thatinstead of building
 the docs you will need to publish them,either via the CMS site
 or through the http://s.apache.org/cms-cliscript.
 
 Nevertheless I'll update the README file in trunk with the full
 details.
 
 
 
 - Original Message -
  From: Graham Leggett minf...@sharp.fm
  To: dev@httpd.apache.org
  Cc: d...@httpd.apache.org d...@httpd.apache.org
  Sent: Wednesday, May 9, 2012 6:06 AM
  Subject: Re: [VOTE] CMS site migration
 
  On 08 May 2012, at 9:14 PM, Joe Schaefer wrote:
 
   Please cast your vote accordingly:
 
   [X] : +1 to migrate httpd-site to the CMS
 
  This is however with the condition that the process to update the CMS is 
  properly documented, and all stale documentation relating to the old way of 
 
  doing things is removed, so there is no chance for confusion.
 
  Regards,
  Graham
  --
 

Re: [VOTE] CMS site migration

[Joe Schaefer]

Death to tables for styling html!



- Original Message -
 From: Daniel Gruno rum...@cord.dk
 To: dev@httpd.apache.org
 Cc: 
 Sent: Wednesday, May 9, 2012 8:38 AM
 Subject: Re: [VOTE] CMS site migration
 
 On 08 May 2012, at 9:14 PM, Joe Schaefer wrote:
 
  Please cast your vote accordingly:
 
  [X] : +1 to migrate httpd-site to the CMS
 
 
 Since I'm the evil munchkin behind a lot of this, I should probably vote
 as well. So there :).
 

[VOTE] CMS site migration

[Joe Schaefer]

Please cast your vote accordingly:

[ ] : +1 to migrate httpd-site to the CMS
[ ] :  0 don't care one way or the other
[ ] : -1 leave httpd-site as-is, because...

Note: this vote is only for httpd-site, not
any of the externals (eg the docs trees) that are pulled in.

T-72 hours before the results are tallied.
Voting rules are majority-consensus, same
as for releases.

Re: [VOTE] CMS site migration

[Joe Schaefer]

 Please cast your vote accordingly:
 
 [X] : +1 to migrate httpd-site to the CMS

Re: [DISCUSS] CMS site migration

[Joe Schaefer]

See http://www.apache/org/dev/cms and 

http://www.apache.org/dev/cmsref for details
on the CMS.



- Original Message -
 From: Brian J. France br...@brianfrance.com
 To: dev@httpd.apache.org; Joe Schaefer joe_schae...@yahoo.com
 Cc: d...@httpd.apache.org d...@httpd.apache.org
 Sent: Monday, May 7, 2012 8:10 AM
 Subject: Re: [DISCUSS] CMS site migration
 
 Do you have details on the on the new CMS, format, conversions, etc?  We us 
 the 
 httpd current format at work for our internal modules and might want to 
 transition to the CMS as well.
 
 Thanks,
 
 Brian
 
 On May 6, 2012, at 5:39 PM, Joe Schaefer wrote:
 
  Over on docs@ one of the recent conversations was
  around moving the site documentation to the CMS,
  starting first with the httpd site as a testbed.
  After several hours of hacking on the site that
  has now been accomplished, so we'd please like everyone
  to review and comment on the httpd staging site now
  available at 
 
      http://httpd.staging.apache.org/
 
  which is perfectly compatible with the CMS's bookmarklet.
  There are a few remaining syntax/style issues that need
  addressing, but otherwise the content has been successfully
  migrated from xdoc to markdown.
 
  The sooner we can push this work into production the
  less hassle it will be to keep the xdoc and content
  trees in sync using two separate build systems.
 
  After a few days have passed if there are no outstanding
  issues remaining I plan to ask for a VOTE to finish the
  migration of httpd-site to the CMS.  Thanks in advance
  for your consideration!
 
 

[DISCUSS] CMS site migration

[Joe Schaefer]

Over on docs@ one of the recent conversations was
around moving the site documentation to the CMS,
starting first with the httpd site as a testbed.
After several hours of hacking on the site that
has now been accomplished, so we'd please like everyone
to review and comment on the httpd staging site now
available at 

    http://httpd.staging.apache.org/

which is perfectly compatible with the CMS's bookmarklet.
There are a few remaining syntax/style issues that need
addressing, but otherwise the content has been successfully
migrated from xdoc to markdown.

The sooner we can push this work into production the
less hassle it will be to keep the xdoc and content
trees in sync using two separate build systems.

After a few days have passed if there are no outstanding
issues remaining I plan to ask for a VOTE to finish the
migration of httpd-site to the CMS.  Thanks in advance
for your consideration!

What is apreq?

[Joe Schaefer]

Lately lots of different httpd folks are asking me
questions about apreq, and from that feedback this
post seems to be needed to clarify what apreq's design
and goals are all about.

Simply put, apreq implements the HTML form specs on
the server side.  The name itself was coined by Lincoln
Stein and Doug Maceachern mainly aimed at addressing
a deficiency in the request_rec struct- namely that it
doesn't do any processing of query strings and POST data.
The original perl package was called Apache::Request
and that's where the apreq monkier comes from- it is
NOT a client-side HTTP request library like neon or serf-
totally unrelated technologies to apreq.

There are two distinct parts to apreq's current implementation-
the library, libapreq2, and the httpd filter module mod_apreq2.

libapreq2 (which is the stuff currently sitting in trunk/server)
depends entirely on libapr and libaprutil- there are no httpd-specific
parts involved in it.  Actual end users of libapreq2 go through
the apreq module API, and libapreq2 provides both a CGI/FCGI
module, and a feed the parser yourself generic module, but
people who want to write httpd modules need mod_apreq2 which
is both an httpd module and an apreq module- the two files
comprising the implementation of mod_apreq2 reflect this division.

The reason apreq has a module api at all is because we wanted
to make available to C programmers a HTML form processing lib
that will essentially remain source-compatible within any implementation
context at all, be it CGI, FCGI, or httpd.  This is something
most dynamic languages that hook into httpd provide essentially
for free, but with apreq it becomes feasible to provide that
functionality to C programmers as well.  The only apreq-based
source changes that are specific to the programming environment
are the selection and instantiation of an appropriate handler
based on whatever module you need to use for that environment-
something easily dealt with using #ifdefs.  Unfortunately this
aspect will be lost unless libapreq2 continues to be made available
as a separate object from httpd itself.


I've personally scrutinized virtually every line in apreq's sources
several times over now, so I'm fairly confident enough in it to say
that the implementation is safe to use and will perform as well or
better than any similar tech out there (when used properly).  That's
not to claim there are no outstanding security issues within the code,
just that nothing obviously exploitable/dosable stands out on a cursory
source scan.  And apreq minimizes strcpy-like operations, preferring
zero-copy algos as much as is feasible.  It also supports HTTP chunked
POST requests which is a novel feature for this sort of thing, no other
lib that I've looked at does that.


Anyway that's a brief overview of apreq, if people have followup questions
I'd be happy to address them.

HTH

Re: packaging libapreq2 as a dependency

[Joe Schaefer]

 From: Issac Goldstand mar...@beamartyr.net
To: dev@httpd.apache.org 
Sent: Friday, April 27, 2012 1:55 AM
Subject: Re: packaging libapreq2 as a dependency
 

On 27/04/2012 05:12, Joe Schaefer wrote: 
Now that some time has passed since Philip brought
apreq2 into trunk it's probably a good time to discuss
how best to incorporate it into httpd itself.  Right
now the library files are in server/ which basically
means we're internally compiling libapreq2 into httpd.


Personally I'd prefer to see libapreq2 bundled as an
upstream dependency, ie put the library into an associated
deps package or just something in srclib/ so it will
provide an independent library file (static, dynamic, or both)
so all users including httpd can link to that object. The

apreq devs spent a considerable amount of time writing
the apreq module api so people could use apreq in any
C context- within an httpd module, a CGI script, or an
fcgi daemon.  It'd be nice to preserve that flexibility
going forward.


Anyway I'm certainly willing to work on libapreq's build system
so it will not be dependent on apxs- it should be really easy
to do given that we just need apxs in a very limited way (basically
to get at the apr-*-config package scripts), I
just need to make the apache2 module build optional so just
the library gets built.  That would entail pulling the apreq
source files out of server/ and just leaving the apreq2
filter module as part of httpd's build system.




+0

I'm +1 for splitting and putting apreq2 filter in the build system;
it's what to do with libapreq2 that holds me back...

I don't like the idea of yet another library/dependency for
building httpd, but after thinking about it, I probably wouldn't
want it as more clutter either in APR or in libhttpd either.  I'd
likely change that to a +1 on the whole if I had even a whisper of a
rumor if anyone (other than the mod_perl folks) was planning on
incorporating apreq into some existing software to justify it being
a standalone library.  I know we built for it, but I've yet to see
real adoption.


I'm not going to get into the whole question of who uses apreq outside
of mod_perl with you, because that's a boring waste of my time.  The fact
that the ASF does should suffice.  The point of the apreq module api is
to allow C authors to scale cleanly in either direction- it'd be a shame to 
abandon
a feature for C programmers that's already available to virtually every
dynamic programming language at this point.


Personally I'd just follow the mod_ldap module design for apreq and just
link the mod_apreq2 filter module to libapreq2.  That avoids the whole bloatware
question about having it as a core dependency- users don't configure it in, it 
doesn't
effect the httpd build.  Package managers could determine for themselves whether
or not to build apreq in by default.


What I'm really looking for btw is an easy migration path for existing mod_perl
users that provides the full featureset of libapreq2 in perl.  Right now the
simplest thing I can think of is to leave mod_apreq2 in httpd's tree and move
the corresponding single-function XS for that module into mod_perl2 (once 
mod_perl
is ready to start supporting 2.4).  Dropping the modules dir from libapreq's 
build
system is a one-line change- we'd of course keep the perl glue support for 
APR::Request.

packaging libapreq2 as a dependency

[Joe Schaefer]

Now that some time has passed since Philip brought
apreq2 into trunk it's probably a good time to discuss
how best to incorporate it into httpd itself.  Right
now the library files are in server/ which basically
means we're internally compiling libapreq2 into httpd.

Personally I'd prefer to see libapreq2 bundled as an
upstream dependency, ie put the library into an associated
deps package or just something in srclib/ so it will
provide an independent library file (static, dynamic, or both)
so all users including httpd can link to that object. The

apreq devs spent a considerable amount of time writing
the apreq module api so people could use apreq in any
C context- within an httpd module, a CGI script, or an
fcgi daemon.  It'd be nice to preserve that flexibility
going forward.

Anyway I'm certainly willing to work on libapreq's build system
so it will not be dependent on apxs- it should be really easy
to do given that we just need apxs in a very limited way (basically
to get at the apr-*-config package scripts), I
just need to make the apache2 module build optional so just
the library gets built.  That would entail pulling the apreq
source files out of server/ and just leaving the apreq2
filter module as part of httpd's build system.


Thoughts?

Re: [RESULT] Re: [VOTE] Release Apache httpd 2.4.1

[Joe Schaefer]

Congrats folks, way to go!



- Original Message -
 From: Jim Jagielski j...@jagunet.com
 To: dev@httpd.apache.org
 Cc: 
 Sent: Friday, February 17, 2012 8:42 AM
 Subject: [RESULT] Re: [VOTE] Release Apache httpd 2.4.1
 
 With the voting ending, I see the following results:
 
   +1 (binding): jorton, sf, kbrand, rjung, minfrin, jim
   +1 (non-binding): Noel Butler, Steffen, mturk, Gregg Smith, Mario Bland,
   +0:
   -1:
 
 As such, I call the vote as PASSING and that httpd 2.4.1 will
 be released as GA.
 
 I will move the tarballs over to dist so the mirrors have the
 weekend to sync up. I expect to announce the release
 next week, complimented with a PR as well.
 
 Thanks to ALL developers, users, testers, etc... This is truly
 another milestone in the httpd history and my deep thanks and
 congratulations go to all who helped make it happen!!
                     
 On Feb 13, 2012, at 8:56 AM, Jim Jagielski wrote:
 
  The 2.4.1 (candidate) tarballs are available for download and test:
 
      http://httpd.apache.org/dev/dist/
 
  I'm calling a VOTE on releasing these as Apache httpd 2.4.1 GA.
  NOTE: The -deps tarballs are included here *only* to make life
  easier for the tester. They will not be, and are not, part
  of the official release.
 
   [ ] +1: Good to go
   [ ] +0: meh
   [ ] -1: Danger Will Robinson. And why.
 
  Vote will last the normal 72 hrs.
 

2.3.16 rewrite bug wrt query strings

[Joe Schaefer]

I just reverted www.apache.org back to 2.3.15 due to 

a bug in query-string handling for mod_rewrite in 2.3.16.
For some reason query-strings are no longer being appended
to typical rewrite rules.

HTH