Mailing List Archive

1 2  View All
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
Missed one. The patch that introduced these changes was revision=1895107.



On Sat, Oct 29, 2022 at 9:15 PM Joe Schaefer <joe@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 <joe@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 <joe@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 <joe@sunstarsys.com> wrote:
>>>
>>>>
>>>> On Sat, Oct 29, 2022 at 1:16 PM Joe Schaefer <joe@sunstarsys.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sat, Oct 29, 2022 at 1:00 PM Yann Ylavic <ylavic.dev@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Joe,
>>>>>>
>>>>>> here comes the "goofer".
>>>>>>
>>>>>> On Fri, Oct 28, 2022 at 9:05 PM <joe@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 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.
>>>>> <joe@sunstarsys.com>
>>>>> 954.253.3732 <//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, &val, &vlen),
>>>> + 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.
>>>> <joe@sunstarsys.com>
>>>> 954.253.3732 <//954.253.3732>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> <joe@sunstarsys.com>
>>> 954.253.3732 <//954.253.3732>
>>>
>>>
>>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
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 <joe@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 <joe@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 <joe@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 <joe@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 <joe@sunstarsys.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On Sat, Oct 29, 2022 at 1:16 PM Joe Schaefer <joe@sunstarsys.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Oct 29, 2022 at 1:00 PM Yann Ylavic <ylavic.dev@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Joe,
>>>>>>>
>>>>>>> here comes the "goofer".
>>>>>>>
>>>>>>> On Fri, Oct 28, 2022 at 9:05 PM <joe@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 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.
>>>>>> <joe@sunstarsys.com>
>>>>>> 954.253.3732 <//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, &val,
>>>>> &vlen),
>>>>> + 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.
>>>>> <joe@sunstarsys.com>
>>>>> 954.253.3732 <//954.253.3732>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Joe Schaefer, Ph.D.
>>>> We only build what you need built.
>>>> <joe@sunstarsys.com>
>>>> 954.253.3732 <//954.253.3732>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> <joe@sunstarsys.com>
>>> 954.253.3732 <//954.253.3732>
>>>
>>>
>>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
> --
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
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 <joe@sunstarsys.com>
Sent: Sunday, October 30, 2022 12:09:02 AM
To: dev@httpd.apache.org <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 <joe@sunstarsys.com<mailto:joe@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 <joe@sunstarsys.com<mailto:joe@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 <joe@sunstarsys.com<mailto:joe@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 <joe@sunstarsys.com<mailto:joe@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 <joe@sunstarsys.com<mailto:joe@sunstarsys.com>> wrote:

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


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

here comes the "goofer".

On Fri, Oct 28, 2022 at 9:05 PM <joe@sunstarsys.com<mailto:joe@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 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.
[https://ci3.googleusercontent.com/mail-sig/AIorK4xJ9wGYA7VWN-zW0DcpKll4IC6JxLGTMmDkmdn4h4eHliQhOGGu1nAHJcSkYVnw1jXF8E--UGA]
We only build what you need built.
<joe@sunstarsys.com<mailto:joe@sunstarsys.com>>
954.253.3732<tel://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, &val, &vlen),
+ 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.
[https://ci3.googleusercontent.com/mail-sig/AIorK4xJ9wGYA7VWN-zW0DcpKll4IC6JxLGTMmDkmdn4h4eHliQhOGGu1nAHJcSkYVnw1jXF8E--UGA]
We only build what you need built.
<joe@sunstarsys.com<mailto:joe@sunstarsys.com>>
954.253.3732<tel://954.253.3732>




--
Joe Schaefer, Ph.D.
[https://ci3.googleusercontent.com/mail-sig/AIorK4xJ9wGYA7VWN-zW0DcpKll4IC6JxLGTMmDkmdn4h4eHliQhOGGu1nAHJcSkYVnw1jXF8E--UGA]
We only build what you need built.
<joe@sunstarsys.com<mailto:joe@sunstarsys.com>>
954.253.3732<tel://954.253.3732>




--
Joe Schaefer, Ph.D.
[https://ci3.googleusercontent.com/mail-sig/AIorK4xJ9wGYA7VWN-zW0DcpKll4IC6JxLGTMmDkmdn4h4eHliQhOGGu1nAHJcSkYVnw1jXF8E--UGA]
We only build what you need built.
<joe@sunstarsys.com<mailto:joe@sunstarsys.com>>
954.253.3732<tel://954.253.3732>


--
Joe Schaefer, Ph.D.
[https://ci3.googleusercontent.com/mail-sig/AIorK4xJ9wGYA7VWN-zW0DcpKll4IC6JxLGTMmDkmdn4h4eHliQhOGGu1nAHJcSkYVnw1jXF8E--UGA]
We only build what you need built.
<joe@sunstarsys.com<mailto:joe@sunstarsys.com>>
954.253.3732<tel://954.253.3732>




--
Joe Schaefer, Ph.D.
[https://ci3.googleusercontent.com/mail-sig/AIorK4xJ9wGYA7VWN-zW0DcpKll4IC6JxLGTMmDkmdn4h4eHliQhOGGu1nAHJcSkYVnw1jXF8E--UGA]
We only build what you need built.
<joe@sunstarsys.com<mailto:joe@sunstarsys.com>>
954.253.3732<tel://954.253.3732>


--
Joe Schaefer, Ph.D.
[https://ci3.googleusercontent.com/mail-sig/AIorK4xJ9wGYA7VWN-zW0DcpKll4IC6JxLGTMmDkmdn4h4eHliQhOGGu1nAHJcSkYVnw1jXF8E--UGA]
We only build what you need built.
<joe@sunstarsys.com<mailto:joe@sunstarsys.com>>
954.253.3732<tel://954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
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 [ In reply to ]
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 <jorton@redhat.com>
Sent: Monday, October 31, 2022 11:07:02 AM
To: dev@httpd.apache.org <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 [ In reply to ]
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.


Regards

R?diger
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
On 10/31/22 5:21 PM, Ruediger Pluem wrote:
>
>
> 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.

Having said this, lets move forward and get into the details which cases are broken and what parts of the code cause this and
should be different.

Regards

R?diger
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Ruediger Pluem <rpluem@apache.org>
Sent: Monday, October 31, 2022 12:21 PM
To: dev@httpd.apache.org <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 [ In reply to ]
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 <joe@sunstarsys.com> wrote:

>
>
> Get Outlook for iOS <https://aka.ms/o0ukef>
> ------------------------------
> *From:* Ruediger Pluem <rpluem@apache.org>
> *Sent:* Monday, October 31, 2022 12:21 PM
> *To:* dev@httpd.apache.org <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.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
With regard to the faulty patch this revolves around:
https://svn.apache.org/viewvc?view=revision&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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> wrote:
>
>>
>>
>> Get Outlook for iOS <https://aka.ms/o0ukef>
>> ------------------------------
>> *From:* Ruediger Pluem <rpluem@apache.org>
>> *Sent:* Monday, October 31, 2022 12:21 PM
>> *To:* dev@httpd.apache.org <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.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
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 <joe@sunstarsys.com> wrote:

> With regard to the faulty patch this revolves around:
> https://svn.apache.org/viewvc?view=revision&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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> wrote:
>>
>>>
>>>
>>> Get Outlook for iOS <https://aka.ms/o0ukef>
>>> ------------------------------
>>> *From:* Ruediger Pluem <rpluem@apache.org>
>>> *Sent:* Monday, October 31, 2022 12:21 PM
>>> *To:* dev@httpd.apache.org <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.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
On Mon, Oct 31, 2022 at 7:44 PM Joe Schaefer <joe@sunstarsys.com> 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 cvs@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.
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Yann Ylavic <ylavic.dev@gmail.com>
Sent: Wednesday, November 2, 2022 9:47 AM
To: dev@httpd.apache.org <dev@httpd.apache.org>
Cc: Joe Schaefer <joe@sunstarsys.com>
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 <joe@sunstarsys.com> 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 cvs@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 [ In reply to ]
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 <joe@sunstarsys.com> wrote:

>
>
> Get Outlook for iOS <https://aka.ms/o0ukef>
> ------------------------------
> *From:* Yann Ylavic <ylavic.dev@gmail.com>
> *Sent:* Wednesday, November 2, 2022 9:47 AM
> *To:* dev@httpd.apache.org <dev@httpd.apache.org>
> *Cc:* Joe Schaefer <joe@sunstarsys.com>
> *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 <joe@sunstarsys.com> 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 cvs@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.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
Please add this additional regression test (for the mfd parser with empty
parts).


On Fri, Nov 4, 2022 at 11:12 AM Joe Schaefer <joe@sunstarsys.com> 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 <joe@sunstarsys.com> wrote:
>
>>
>>
>> Get Outlook for iOS <https://aka.ms/o0ukef>
>> ------------------------------
>> *From:* Yann Ylavic <ylavic.dev@gmail.com>
>> *Sent:* Wednesday, November 2, 2022 9:47 AM
>> *To:* dev@httpd.apache.org <dev@httpd.apache.org>
>> *Cc:* Joe Schaefer <joe@sunstarsys.com>
>> *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 <joe@sunstarsys.com> 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 cvs@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.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
Better version (backs out most of an incorrect prior change).

On Fri, Nov 4, 2022 at 11:38 AM Joe Schaefer <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> wrote:
>>
>>>
>>>
>>> Get Outlook for iOS <https://aka.ms/o0ukef>
>>> ------------------------------
>>> *From:* Yann Ylavic <ylavic.dev@gmail.com>
>>> *Sent:* Wednesday, November 2, 2022 9:47 AM
>>> *To:* dev@httpd.apache.org <dev@httpd.apache.org>
>>> *Cc:* Joe Schaefer <joe@sunstarsys.com>
>>> *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 <joe@sunstarsys.com> 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 cvs@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.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
RE: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
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 <ylavic.dev@gmail.com>
Sent: Wednesday, November 2, 2022 9:47 AM
To: dev@httpd.apache.org
Cc: Joe Schaefer <joe@sunstarsys.com>
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 <joe@sunstarsys.com> 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 cvs@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.
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
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 <joe@sunstarsys.com> 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 <ylavic.dev@gmail.com>
> Sent: Wednesday, November 2, 2022 9:47 AM
> To: dev@httpd.apache.org
> Cc: Joe Schaefer <joe@sunstarsys.com>
> 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 <joe@sunstarsys.com> 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 cvs@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.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <ylavic.dev@gmail.com>
>> Sent: Wednesday, November 2, 2022 9:47 AM
>> To: dev@httpd.apache.org
>> Cc: Joe Schaefer <joe@sunstarsys.com>
>> 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 <joe@sunstarsys.com> 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 cvs@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.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
Last patch: this one includes autoconf/automake repairs as well.

On Fri, Nov 4, 2022 at 9:02 PM Joe Schaefer <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <ylavic.dev@gmail.com>
>>> Sent: Wednesday, November 2, 2022 9:47 AM
>>> To: dev@httpd.apache.org
>>> Cc: Joe Schaefer <joe@sunstarsys.com>
>>> 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 <joe@sunstarsys.com> 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 cvs@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.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>

1 2  View All