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]

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.


openpgp-digital-signature.asc
Description: PGP signature

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 
>>> --
>>> *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-disposition: form-data; name=\"pics\"; filename=\"file1.txt\"" CRLF
 "Content-Type: text/plain" CRLF CRLF
 "... contents of file1.txt ..." CRLF CRLF
-"--AaB03x--" CRLF;
-
-/* This (invalid) case used to segfault the parser before r164254 so should
-   be tested separately to form_data:
-   
-static char form_data_fail[] =
+"--AaB03x" CRLF
 "content-disposition: form-data; name=\"\"" CRLF
 "content-type: text/plain;" CRLF " charset=windows-1250" CRLF
 "content-transfer-encoding: quoted-printable" CRLF CRLF
@@ -52,8 +51,6 @@
 "Joe owes =80100." CRLF
 "--AaB03x--" CRLF;
 
-*/
-
 static char xml_data[] =
 ""
 ""
@@ -237,7 +234,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);
+  

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