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

[Joe Schaefer]

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

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

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

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

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

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 

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

[Joe Schaefer]

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.

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

[Yann Ylavic]

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.

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

[Joe Schaefer]

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

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


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

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

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

954.253.3732 

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

[Joe Schaefer]

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

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


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

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

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

954.253.3732 

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

[Joe Schaefer]

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

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

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

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

954.253.3732 

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

[Joe Schaefer]

Get Outlook for iOS

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



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

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




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

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

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

[Ruediger Pluem]

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

[Ruediger Pluem]

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

[Joe Schaefer]

Apologies for the bombast, Joe.

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

Get Outlook for iOS

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

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

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

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

Regards, Joe

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

[Joe Orton]

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

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

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

Regards, Joe

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

[Joe Schaefer]

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

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

Get Outlook for iOS

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

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

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

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



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

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

Here's my patchset, enjoy.









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

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

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

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


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

here comes the "goofer".

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

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

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

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

Fair enough.


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

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

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

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

Then lets deal with it by adding more tests.


>  We’re just racking up CVE’s, people are disabling the mfd parser altogether, 
> 

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

[Joe Schaefer]

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

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

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

> Missed one.  The patch that introduced these changes was revision=1895107.
>
>
>
> On Sat, Oct 29, 2022 at 9:15 PM Joe Schaefer  wrote:
>
>> Of course, I don’t know how to advise you regarding the security aspects,
>> since you’re doing what you thought was the right thing to do and put the
>> mfd parser into an error state instead of leaving well enough alone.  But
>> basically libapreq2 users get annoyed when the parser breaks on valid
>> input, and may get antsy when their server goes bonkers because they aren’t
>> in the habit of doing error handling on this condition.
>>
>> On Sat, Oct 29, 2022 at 8:36 PM Joe Schaefer  wrote:
>>
>>> Found the problem: it's just a misunderstanding about what is admissible
>>> in a successful file upload widget.
>>> If someone doesn't add a file to the upload widget, it is still a
>>> successful control and should be processed as such on the server.
>>> In this case, just like with opera, the filename attribute will be
>>> present, but set to an empty double-quoted string.
>>>
>>> Here's my patchset, enjoy.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Oct 29, 2022 at 2:47 PM Joe Schaefer  wrote:
>>>
 Curiously, this doesn't seem to present any problems for
 apreq_header_attribute in trunk/HEAD.  A good thing.

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

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

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

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

[Joe Schaefer]

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



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

> Of course, I don’t know how to advise you regarding the security aspects,
> since you’re doing what you thought was the right thing to do and put the
> mfd parser into an error state instead of leaving well enough alone.  But
> basically libapreq2 users get annoyed when the parser breaks on valid
> input, and may get antsy when their server goes bonkers because they aren’t
> in the habit of doing error handling on this condition.
>
> On Sat, Oct 29, 2022 at 8:36 PM Joe Schaefer  wrote:
>
>> Found the problem: it's just a misunderstanding about what is admissible
>> in a successful file upload widget.
>> If someone doesn't add a file to the upload widget, it is still a
>> successful control and should be processed as such on the server.
>> In this case, just like with opera, the filename attribute will be
>> present, but set to an empty double-quoted string.
>>
>> Here's my patchset, enjoy.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Oct 29, 2022 at 2:47 PM Joe Schaefer  wrote:
>>
>>> Curiously, this doesn't seem to present any problems for
>>> apreq_header_attribute in trunk/HEAD.  A good thing.
>>>
>>> That means we may need to look more closely at r1903484 in glue/perl.
>>>
>>> On Sat, Oct 29, 2022 at 2:12 PM Joe Schaefer  wrote:
>>>

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

>
>
> On Sat, Oct 29, 2022 at 1:00 PM Yann Ylavic 
> wrote:
>
>> Hi Joe,
>>
>> here comes the "goofer".
>>
>> On Fri, Oct 28, 2022 at 9:05 PM  wrote:
>> >
>> > Long time fan, not a first time caller.
>>
>> Yet what a crappy thread (and comments on [1]).
>> All top posting, unreplyable.
>>
>> >
>> > Libapreq2 was intended to be a safe,fast, standards compliant
>> library- primarily *safe* before all other priorities.  Some of the work
>> going on lately in util.c is starting to undermine that prime directive, 
>> so
>> I’d like to better understand why these changes are happening, and why 
>> they
>> are snowballing into a less functional, less secure software product that
>> is driving up my support costs on CPAN.
>>
>> Yeah sure, rewriting history. That marvelous previous 2.16 just
>> exploded when faced with google's oss-fuzzers (and not just a little,
>> quite some reports) which now fuzz httpd trunk (thus apreq).
>> CVE-2022-22728 is about libapreq2 v2.16 *and earlier" right? So
>> something pre-dated my changes.
>
>
> Fair enough.
>
>
>>
> >
>> > For instance, this revision 1867789 is a pure pessimization:  it
>> trades userland RAM for filesystem cache RAM, that’s it, but it’s not a 
>> big
>> deal.  Just churn.
>>
>> I call it a fix for an UAF (Use After Free). This is my only change in
>> 2.16 btw, while you seem to suggest that security issues started with
>> 2.16.
>>
>> >
>> > Everything in the crufty, old apreq_header_attribute code I wrote
>> was completely tossed and reimplemented.  Why?
>>
>> Someone had to address the security reports, and someone (me) dared
>> touching your code because it was not safe (i.e.
>> broken/crashing/vulnerable/..), not for the lulz nor breaking users.
>> I'm very sorry if that happened, only those who do nothing do not
>> break anything though.
>> Existing tests were still passing, but shit happens.
>>
>
> Then lets deal with it by adding more tests.
>
>
>>
>> >  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

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

[Joe Schaefer]

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

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

> Found the problem: it's just a misunderstanding about what is admissible
> in a successful file upload widget.
> If someone doesn't add a file to the upload widget, it is still a
> successful control and should be processed as such on the server.
> In this case, just like with opera, the filename attribute will be
> present, but set to an empty double-quoted string.
>
> Here's my patchset, enjoy.
>
>
>
>
>
>
>
>
>
> On Sat, Oct 29, 2022 at 2:47 PM Joe Schaefer  wrote:
>
>> Curiously, this doesn't seem to present any problems for
>> apreq_header_attribute in trunk/HEAD.  A good thing.
>>
>> That means we may need to look more closely at r1903484 in glue/perl.
>>
>> On Sat, Oct 29, 2022 at 2:12 PM Joe Schaefer  wrote:
>>
>>>
>>> On Sat, Oct 29, 2022 at 1:16 PM Joe Schaefer  wrote:
>>>


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

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


 Fair enough.


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

 Then lets deal with it by adding more tests.


>
> >  We’re just racking up CVE’s, people are disabling the mfd parser
> altogether, and it no longer support common use cases that people now
> complain about because it supported cases in the wild that the new work
> does not.
>
> Are there multiple issues? I know of the one reported in [1] about
> "file upload does not work if any file fields are blank".
> That's 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 

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

[Joe Schaefer]

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

Here's my patchset, enjoy.









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

> Curiously, this doesn't seem to present any problems for
> apreq_header_attribute in trunk/HEAD.  A good thing.
>
> That means we may need to look more closely at r1903484 in glue/perl.
>
> On Sat, Oct 29, 2022 at 2:12 PM Joe Schaefer  wrote:
>
>>
>> On Sat, Oct 29, 2022 at 1:16 PM Joe Schaefer  wrote:
>>
>>>
>>>
>>> On Sat, Oct 29, 2022 at 1:00 PM Yann Ylavic 
>>> wrote:
>>>
 Hi Joe,

 here comes the "goofer".

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

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

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

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

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

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

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

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

>>>
>>> Then lets deal with it by adding more tests.
>>>
>>>

 >  We’re just racking up CVE’s, people are disabling the mfd parser
 altogether, and it no longer support common use cases that people now
 complain about because it supported cases in the wild that the new work
 does not.

 Are there multiple issues? I know of the one reported in [1] about
 "file upload does not work if any file fields are blank".
 That's not actionable sorry (I don't understand what it means), no
 more than your rant here and elusive "hints" on where/how to fix it.
 I asked in the other thread for a reproducer in the form of a HTTP
 payload, not a mod_perl handler which I don't know how to debug (let
 alone without the right thing to send on the client side).


>>> I translated the bug report for you.  It involves browsers like Opera
>>> that send  filename=""
>>> attributes in the Content-Disposition header.  It's generating an
>>> accidental DoS, depending
>>> on how people use the upload API.  Toss in some tests into util.t and
>>> I'll add this one for you.
>>>
>>>
 >
 > With the latest code coming out of p5p for Perl, there’s a whole new
 reason for excitement in httpd-land: the mod_perl2 + mpm_event combination
 is rock solid and screaming fast with HTTP/2.  The only reason I resubbed
 here is in the hopes of some synergy retaking these perl-related projects,
 since mod_perl2 is the only game in town for embedded interpreters in
 httpd2 (and no, lua is not the answer, it’s not thread safe either).

 Synergy! What a great intro..


 Regards;
 Yann.

 [1] https://rt.cpan.org/Public/Bug/Display.html?id=144470

>>>
>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> 
>>> 954.253.3732 
>>>
>>>
>>>
>>
>> Let's start with this (untested) patch...
>>
>>
>> Index: library/t/util.c
>> ===
>> --- library/t/util.c(revision 1904922)
>> +++ library/t/util.c(working copy)
>> @@ -271,6 +271,7 @@
>>  static void test_header_attribute(dAT, void *ctx)
>>  {
>>  const char hdr[] = "name=\"filename=foo\"; filename=\"quux.txt\"";
>> +

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

[Joe Schaefer]

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

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

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

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

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

[Joe Schaefer]

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

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

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


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

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

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

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

954.253.3732 

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

[Joe Schaefer]

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

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

> F/OSS is not about telling others how to write their code, Joe. You know
> this. And it *definitely* is not about demanding they spend *their* time to
> fix your pet issues.
>
> If you have a problem with the code, then supply a fix. Your dozen emails
> are not fixing anything, and are certainly not endearing anybody to help
> you. Be nice, if you want help.
>
> -g
>
>
> On Sat, Oct 29, 2022 at 11:11 AM Joe Schaefer  wrote:
>
>> ...fell apart when Max asked you to release his patch to my screwup with
>> the NPE, and instead of cutting a release
>> with just that patch applied, you began the tragic process of dorking
>> around with apreq_header_attribute() as well.
>>
>> Just pull all those hacks out of apreq/trunk, and release exactly what
>> Max told you to release, and you will be good for another quiet decade of
>> happy libapreq2 users.
>>
>> If you do not take this advice, at least for your own personal
>> reputations, stop hacking the logic and  start writing regression tests.
>>  An internet-grade mfd parser is only as good as its weakest link, and I
>> just spent the past day telling you where that is.
>>
>> On Sat, Oct 29, 2022 at 12:06 PM Joe Schaefer  wrote:
>>
>>> All we need to do at this point is remember the basics of how to cut a
>>> security bugfix release.  Everything in libapreq
>>>
>>> On Fri, Oct 28, 2022 at 3:04 PM  wrote:
>>>
 Long time fan, not a first time caller.



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



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



 Everything in the crufty, old apreq_header_attribute code I wrote was
 completely tossed and reimplemented.  Why?  We’re just racking up CVE’s,
 people are disabling the mfd parser altogether, and it no longer support
 common use cases that people now complain about because it supported cases
 in the wild that the new work does not.



 With the latest code coming out of p5p for Perl, there’s a whole new
 reason for excitement in httpd-land: the mod_perl2 + mpm_event combination
 is rock solid and screaming fast with HTTP/2.  The only reason I resubbed
 here is in the hopes of some synergy retaking these perl-related projects,
 since mod_perl2 is the only game in town for embedded interpreters in
 httpd2 (and no, lua is not the answer, it’s not thread safe either).





 Joe Schaefer, Ph.D.

 

 954.253.3732 

 SunStar Systems CMS  *- The Original
 Markdown JAM Stack**™*



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

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

954.253.3732 

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

[Greg Stein]

F/OSS is not about telling others how to write their code, Joe. You know
this. And it *definitely* is not about demanding they spend *their* time to
fix your pet issues.

If you have a problem with the code, then supply a fix. Your dozen emails
are not fixing anything, and are certainly not endearing anybody to help
you. Be nice, if you want help.

-g


On Sat, Oct 29, 2022 at 11:11 AM Joe Schaefer  wrote:

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

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

[Joe Schaefer]

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

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


Fair enough.


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

Then lets deal with it by adding more tests.


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


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


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

954.253.3732 

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

[Yann Ylavic]

Hi Joe,

here comes the "goofer".

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

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

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

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

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

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

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

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

[Joe Schaefer]

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

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

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

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

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

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

954.253.3732 

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

[Joe Schaefer]

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

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

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


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

954.253.3732 

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

[Joe Schaefer]

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

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

> There’s likely another CVE to add to the matrix revolving around the way
> the current code deals with an empty file name attribute, given the bizarre
> behavior of the rest of the code that runs after.
>
> On Fri, Oct 28, 2022 at 6:56 PM Joe Schaefer  wrote:
>
>> There simply is no usable libapreq2 release that's not either riddled
>> with CVE's, or actually supports every common browser that submits
>> form-data online.
>> That wasn't apreq developer's doing, it was httpd's.  All you've been
>> doing is pushing alpha quality apreq_header_attribute implementations that
>> you wouldn't dream of shipping in httpd3 GA,
>> and letting libapreq users be your QA department instead of writing tests
>> to demonstrate your bona-fides to tackle this problem appropriately in any
>> GA software project.
>> There's a lot of ways of handling the discrepancy between the code in
>> httpd/trunk and the code in apreq/trunk (our release branch) that doesn't
>> involve this nonsense.
>>
>> You can do better, because I've seen it.  All anyone can ask is for
>> better QA in GA releases in a project that has only seen one dud after the
>> next for three plus years.
>> It will make httpd3 better in the future if you do.
>>
>> On Fri, Oct 28, 2022 at 5:39 PM Joe Schaefer  wrote:
>>
>>> You first.  I'm just an old fart mining the CPAN show for you. I told
>>> you what you need to fix the bug, let's see some bugfixing.
>>>
>>> On Fri, Oct 28, 2022 at 5:24 PM Eric Covener  wrote:
>>>
 If it's the same issue as the one Steve brought up on the 2.17 release
 vote thread, please add something constructive (like a test) there.

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

> The Unit Test infra already exists in the apreq tree.  Just add tests
> to the test files that are already present.
> If it's a pain in the ass to do this with Apache::Test, that's
> irrelevant to the point I'm making.  We don't use Apache::Test for testing
> libapreq2.so
>
> On Fri, Oct 28, 2022 at 5:00 PM Joe Schaefer 
> wrote:
>
>> We don't need to be friends to get along Eric.  We just need httpd to
>> test your code with unit and regression tests before you release it to 
>> the
>> rest of the planet.  After all, it's what we used to do when we cared 
>> about
>> CVE's with parsers.
>>
>> On Fri, Oct 28, 2022 at 4:51 PM Joe Schaefer 
>> wrote:
>>
>>> Hell no.  But there are consequences to treating the project as a
>>> guinea pig for httpd.
>>>
>>> On Fri, Oct 28, 2022 at 4:50 PM Eric Covener 
>>> wrote:
>>>
 Would you like to maintain it outside of httpd?

 my +1 to drop the subproject and rip it from httpd trunk.

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

> The function under scrutiny here is apreq_header_attribute. The
> only use case for that function in a form-data
> parsing library is to deal with the Content-Disposition header,
> which has a very tight MIME spec that does not
> involve rewriting the old code for a generic header attribute
> parser, without anyone filing a bug report about the
> original one.
>
> libapreq2 is an old, stable codebase. The Perl community likes it
> that way. We think it's great when flaws are discovered,
> which means patches are in order.  But it is not the right
> codebase for sloppy experiments with unusable logic over something
> that does the job and has had no discoverable buffer overflows,
> ever.
>
>
> On Fri, Oct 28, 2022 at 3:17 PM Joe Schaefer 
> wrote:
>
>> None of the patches to util.c include corresponding patches to
>> any of the several layers of test suites involved in libapreq.
>> It's starting to wear on our user's nerves.
>>
>> On Fri, Oct 28, 2022 at 3:04 PM  wrote:
>>
>>> Long time fan, not a first time caller.
>>>
>>>
>>>
>>> Libapreq2 was intended to be a safe,fast, standards compliant
>>> library- primarily **safe** before all other priorities.  Some
>>> of the work going on lately in util.c is starting to undermine that 
>>> prime
>>> directive, so I’d like to better understand why these changes are
>>> happening, and why they are snowballing into a less functional, 
>>> less secure
>>> software product that is driving up my support costs on CPAN.
>>>
>>>
>>>
>>> For instance, this revision 1867789 is a pure pessimization:  it
>>> trades 

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

[Joe Schaefer]

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

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

> There simply is no usable libapreq2 release that's not either riddled with
> CVE's, or actually supports every common browser that submits form-data
> online.
> That wasn't apreq developer's doing, it was httpd's.  All you've been
> doing is pushing alpha quality apreq_header_attribute implementations that
> you wouldn't dream of shipping in httpd3 GA,
> and letting libapreq users be your QA department instead of writing tests
> to demonstrate your bona-fides to tackle this problem appropriately in any
> GA software project.
> There's a lot of ways of handling the discrepancy between the code in
> httpd/trunk and the code in apreq/trunk (our release branch) that doesn't
> involve this nonsense.
>
> You can do better, because I've seen it.  All anyone can ask is for better
> QA in GA releases in a project that has only seen one dud after the next
> for three plus years.
> It will make httpd3 better in the future if you do.
>
> On Fri, Oct 28, 2022 at 5:39 PM Joe Schaefer  wrote:
>
>> You first.  I'm just an old fart mining the CPAN show for you. I told you
>> what you need to fix the bug, let's see some bugfixing.
>>
>> On Fri, Oct 28, 2022 at 5:24 PM Eric Covener  wrote:
>>
>>> If it's the same issue as the one Steve brought up on the 2.17 release
>>> vote thread, please add something constructive (like a test) there.
>>>
>>> On Fri, Oct 28, 2022 at 5:15 PM Joe Schaefer  wrote:
>>>
 The Unit Test infra already exists in the apreq tree.  Just add tests
 to the test files that are already present.
 If it's a pain in the ass to do this with Apache::Test, that's
 irrelevant to the point I'm making.  We don't use Apache::Test for testing
 libapreq2.so

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

> We don't need to be friends to get along Eric.  We just need httpd to
> test your code with unit and regression tests before you release it to the
> rest of the planet.  After all, it's what we used to do when we cared 
> about
> CVE's with parsers.
>
> On Fri, Oct 28, 2022 at 4:51 PM Joe Schaefer 
> wrote:
>
>> Hell no.  But there are consequences to treating the project as a
>> guinea pig for httpd.
>>
>> On Fri, Oct 28, 2022 at 4:50 PM Eric Covener 
>> wrote:
>>
>>> Would you like to maintain it outside of httpd?
>>>
>>> my +1 to drop the subproject and rip it from httpd trunk.
>>>
>>> On Fri, Oct 28, 2022 at 3:51 PM Joe Schaefer 
>>> wrote:
>>>
 The function under scrutiny here is apreq_header_attribute. The
 only use case for that function in a form-data
 parsing library is to deal with the Content-Disposition header,
 which has a very tight MIME spec that does not
 involve rewriting the old code for a generic header attribute
 parser, without anyone filing a bug report about the
 original one.

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


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

> None of the patches to util.c include corresponding patches to any
> of the several layers of test suites involved in libapreq.
> It's starting to wear on our user's nerves.
>
> On Fri, Oct 28, 2022 at 3:04 PM  wrote:
>
>> Long time fan, not a first time caller.
>>
>>
>>
>> Libapreq2 was intended to be a safe,fast, standards compliant
>> library- primarily **safe** before all other priorities.  Some
>> of the work going on lately in util.c is starting to undermine that 
>> prime
>> directive, so I’d like to better understand why these changes are
>> happening, and why they are snowballing into a less functional, less 
>> secure
>> software product that is driving up my support costs on CPAN.
>>
>>
>>
>> For instance, this revision 1867789 is a pure pessimization:  it
>> trades userland RAM for filesystem cache RAM, that’s it, but it’s 
>> not a big
>> deal.  Just churn.
>>
>>
>>
>> Everything in the crufty, old apreq_header_attribute code I wrote
>> was completely tossed and reimplemented.  Why?  We’re just racking up
>> CVE’s, people are disabling the mfd parser 

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

[Joe Schaefer]

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

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

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

> You first.  I'm just an old fart mining the CPAN show for you. I told you
> what you need to fix the bug, let's see some bugfixing.
>
> On Fri, Oct 28, 2022 at 5:24 PM Eric Covener  wrote:
>
>> If it's the same issue as the one Steve brought up on the 2.17 release
>> vote thread, please add something constructive (like a test) there.
>>
>> On Fri, Oct 28, 2022 at 5:15 PM Joe Schaefer  wrote:
>>
>>> The Unit Test infra already exists in the apreq tree.  Just add tests to
>>> the test files that are already present.
>>> If it's a pain in the ass to do this with Apache::Test, that's
>>> irrelevant to the point I'm making.  We don't use Apache::Test for testing
>>> libapreq2.so
>>>
>>> On Fri, Oct 28, 2022 at 5:00 PM Joe Schaefer  wrote:
>>>
 We don't need to be friends to get along Eric.  We just need httpd to
 test your code with unit and regression tests before you release it to the
 rest of the planet.  After all, it's what we used to do when we cared about
 CVE's with parsers.

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

> Hell no.  But there are consequences to treating the project as a
> guinea pig for httpd.
>
> On Fri, Oct 28, 2022 at 4:50 PM Eric Covener 
> wrote:
>
>> Would you like to maintain it outside of httpd?
>>
>> my +1 to drop the subproject and rip it from httpd trunk.
>>
>> On Fri, Oct 28, 2022 at 3:51 PM Joe Schaefer 
>> wrote:
>>
>>> The function under scrutiny here is apreq_header_attribute. The only
>>> use case for that function in a form-data
>>> parsing library is to deal with the Content-Disposition header,
>>> which has a very tight MIME spec that does not
>>> involve rewriting the old code for a generic header attribute
>>> parser, without anyone filing a bug report about the
>>> original one.
>>>
>>> libapreq2 is an old, stable codebase. The Perl community likes it
>>> that way. We think it's great when flaws are discovered,
>>> which means patches are in order.  But it is not the right codebase
>>> for sloppy experiments with unusable logic over something
>>> that does the job and has had no discoverable buffer overflows, ever.
>>>
>>>
>>> On Fri, Oct 28, 2022 at 3:17 PM Joe Schaefer 
>>> wrote:
>>>
 None of the patches to util.c include corresponding patches to any
 of the several layers of test suites involved in libapreq.
 It's starting to wear on our user's nerves.

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

> Long time fan, not a first time caller.
>
>
>
> Libapreq2 was intended to be a safe,fast, standards compliant
> library- primarily **safe** before all other priorities.  Some of
> the work going on lately in util.c is starting to undermine that prime
> directive, so I’d like to better understand why these changes are
> happening, and why they are snowballing into a less functional, less 
> secure
> software product that is driving up my support costs on CPAN.
>
>
>
> For instance, this revision 1867789 is a pure pessimization:  it
> trades userland RAM for filesystem cache RAM, that’s it, but it’s not 
> a big
> deal.  Just churn.
>
>
>
> Everything in the crufty, old apreq_header_attribute code I wrote
> was completely tossed and reimplemented.  Why?  We’re just racking up
> CVE’s, people are disabling the mfd parser altogether, and it no 
> longer
> support common use cases that people now complain about because it
> supported cases in the wild that the new work does not.
>
>
>
> With the latest code coming out of p5p for Perl, there’s a whole
> new reason for excitement in httpd-land: the mod_perl2 + mpm_event
> combination is rock solid and screaming 

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

[Joe Schaefer]

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

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

> If it's the same issue as the one Steve brought up on the 2.17 release
> vote thread, please add something constructive (like a test) there.
>
> On Fri, Oct 28, 2022 at 5:15 PM Joe Schaefer  wrote:
>
>> The Unit Test infra already exists in the apreq tree.  Just add tests to
>> the test files that are already present.
>> If it's a pain in the ass to do this with Apache::Test, that's irrelevant
>> to the point I'm making.  We don't use Apache::Test for testing libapreq2.so
>>
>> On Fri, Oct 28, 2022 at 5:00 PM Joe Schaefer  wrote:
>>
>>> We don't need to be friends to get along Eric.  We just need httpd to
>>> test your code with unit and regression tests before you release it to the
>>> rest of the planet.  After all, it's what we used to do when we cared about
>>> CVE's with parsers.
>>>
>>> On Fri, Oct 28, 2022 at 4:51 PM Joe Schaefer  wrote:
>>>
 Hell no.  But there are consequences to treating the project as a
 guinea pig for httpd.

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

> Would you like to maintain it outside of httpd?
>
> my +1 to drop the subproject and rip it from httpd trunk.
>
> On Fri, Oct 28, 2022 at 3:51 PM Joe Schaefer 
> wrote:
>
>> The function under scrutiny here is apreq_header_attribute. The only
>> use case for that function in a form-data
>> parsing library is to deal with the Content-Disposition header,
>> which has a very tight MIME spec that does not
>> involve rewriting the old code for a generic header attribute parser,
>> without anyone filing a bug report about the
>> original one.
>>
>> libapreq2 is an old, stable codebase. The Perl community likes it
>> that way. We think it's great when flaws are discovered,
>> which means patches are in order.  But it is not the right codebase
>> for sloppy experiments with unusable logic over something
>> that does the job and has had no discoverable buffer overflows, ever.
>>
>>
>> On Fri, Oct 28, 2022 at 3:17 PM Joe Schaefer 
>> wrote:
>>
>>> None of the patches to util.c include corresponding patches to any
>>> of the several layers of test suites involved in libapreq.
>>> It's starting to wear on our user's nerves.
>>>
>>> On Fri, Oct 28, 2022 at 3:04 PM  wrote:
>>>
 Long time fan, not a first time caller.



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



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



 Everything in the crufty, old apreq_header_attribute code I wrote
 was completely tossed and reimplemented.  Why?  We’re just racking up
 CVE’s, people are disabling the mfd parser altogether, and it no longer
 support common use cases that people now complain about because it
 supported cases in the wild that the new work does not.



 With the latest code coming out of p5p for Perl, there’s a whole
 new reason for excitement in httpd-land: the mod_perl2 + mpm_event
 combination is rock solid and screaming fast with HTTP/2.  The only 
 reason
 I resubbed here is in the hopes of some synergy retaking these 
 perl-related
 projects, since mod_perl2 is the only game in town for embedded
 interpreters in httpd2 (and no, lua is not the answer, it’s not thread 
 safe
 either).





 Joe Schaefer, Ph.D.

 

 954.253.3732 

 SunStar Systems CMS  *- The Original
 Markdown JAM Stack**™*



>>>
>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> 
>>> 954.253.3732 
>>>
>>>
>>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> 
>> 954.253.3732 
>>
>>
>>
>
> --
> Eric Covener
> cove...@gmail.com
>


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



>>>
>>> --

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

[Joe Schaefer]

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

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

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

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



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

> The Unit Test infra already exists in the apreq tree.  Just add tests to
> the test files that are already present.
> If it's a pain in the ass to do this with Apache::Test, that's irrelevant
> to the point I'm making.  We don't use Apache::Test for testing libapreq2.so
>
> On Fri, Oct 28, 2022 at 5:00 PM Joe Schaefer  wrote:
>
>> We don't need to be friends to get along Eric.  We just need httpd to
>> test your code with unit and regression tests before you release it to the
>> rest of the planet.  After all, it's what we used to do when we cared about
>> CVE's with parsers.
>>
>> On Fri, Oct 28, 2022 at 4:51 PM Joe Schaefer  wrote:
>>
>>> Hell no.  But there are consequences to treating the project as a guinea
>>> pig for httpd.
>>>
>>> On Fri, Oct 28, 2022 at 4:50 PM Eric Covener  wrote:
>>>
 Would you like to maintain it outside of httpd?

 my +1 to drop the subproject and rip it from httpd trunk.

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

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

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

[Eric Covener]

If it's the same issue as the one Steve brought up on the 2.17 release vote
thread, please add something constructive (like a test) there.

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

> The Unit Test infra already exists in the apreq tree.  Just add tests to
> the test files that are already present.
> If it's a pain in the ass to do this with Apache::Test, that's irrelevant
> to the point I'm making.  We don't use Apache::Test for testing libapreq2.so
>
> On Fri, Oct 28, 2022 at 5:00 PM Joe Schaefer  wrote:
>
>> We don't need to be friends to get along Eric.  We just need httpd to
>> test your code with unit and regression tests before you release it to the
>> rest of the planet.  After all, it's what we used to do when we cared about
>> CVE's with parsers.
>>
>> On Fri, Oct 28, 2022 at 4:51 PM Joe Schaefer  wrote:
>>
>>> Hell no.  But there are consequences to treating the project as a guinea
>>> pig for httpd.
>>>
>>> On Fri, Oct 28, 2022 at 4:50 PM Eric Covener  wrote:
>>>
 Would you like to maintain it outside of httpd?

 my +1 to drop the subproject and rip it from httpd trunk.

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

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

 --
 Eric Covener
 cove...@gmail.com

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

-- 
Eric Covener
cove...@gmail.com

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

[Joe Schaefer]

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

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

> We don't need to be friends to get along Eric.  We just need httpd to test
> your code with unit and regression tests before you release it to the rest
> of the planet.  After all, it's what we used to do when we cared about
> CVE's with parsers.
>
> On Fri, Oct 28, 2022 at 4:51 PM Joe Schaefer  wrote:
>
>> Hell no.  But there are consequences to treating the project as a guinea
>> pig for httpd.
>>
>> On Fri, Oct 28, 2022 at 4:50 PM Eric Covener  wrote:
>>
>>> Would you like to maintain it outside of httpd?
>>>
>>> my +1 to drop the subproject and rip it from httpd trunk.
>>>
>>> On Fri, Oct 28, 2022 at 3:51 PM Joe Schaefer  wrote:
>>>
 The function under scrutiny here is apreq_header_attribute. The only
 use case for that function in a form-data
 parsing library is to deal with the Content-Disposition header,
 which has a very tight MIME spec that does not
 involve rewriting the old code for a generic header attribute parser,
 without anyone filing a bug report about the
 original one.

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


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

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

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



>>>
>>> --
>>> Eric Covener
>>> cove...@gmail.com
>>>
>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> 
>> 954.253.3732 
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

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

954.253.3732 

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

[Joe Schaefer]

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

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

> Hell no.  But there are consequences to treating the project as a guinea
> pig for httpd.
>
> On Fri, Oct 28, 2022 at 4:50 PM Eric Covener  wrote:
>
>> Would you like to maintain it outside of httpd?
>>
>> my +1 to drop the subproject and rip it from httpd trunk.
>>
>> On Fri, Oct 28, 2022 at 3:51 PM Joe Schaefer  wrote:
>>
>>> The function under scrutiny here is apreq_header_attribute. The only use
>>> case for that function in a form-data
>>> parsing library is to deal with the Content-Disposition header,
>>> which has a very tight MIME spec that does not
>>> involve rewriting the old code for a generic header attribute parser,
>>> without anyone filing a bug report about the
>>> original one.
>>>
>>> libapreq2 is an old, stable codebase. The Perl community likes it that
>>> way. We think it's great when flaws are discovered,
>>> which means patches are in order.  But it is not the right codebase for
>>> sloppy experiments with unusable logic over something
>>> that does the job and has had no discoverable buffer overflows, ever.
>>>
>>>
>>> On Fri, Oct 28, 2022 at 3:17 PM Joe Schaefer  wrote:
>>>
 None of the patches to util.c include corresponding patches to any of
 the several layers of test suites involved in libapreq.
 It's starting to wear on our user's nerves.

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

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


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



>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> 
>>> 954.253.3732 
>>>
>>>
>>>
>>
>> --
>> Eric Covener
>> cove...@gmail.com
>>
>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

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

954.253.3732 

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

[Joe Schaefer]

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

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

> Would you like to maintain it outside of httpd?
>
> my +1 to drop the subproject and rip it from httpd trunk.
>
> On Fri, Oct 28, 2022 at 3:51 PM Joe Schaefer  wrote:
>
>> The function under scrutiny here is apreq_header_attribute. The only use
>> case for that function in a form-data
>> parsing library is to deal with the Content-Disposition header, which has
>> a very tight MIME spec that does not
>> involve rewriting the old code for a generic header attribute parser,
>> without anyone filing a bug report about the
>> original one.
>>
>> libapreq2 is an old, stable codebase. The Perl community likes it that
>> way. We think it's great when flaws are discovered,
>> which means patches are in order.  But it is not the right codebase for
>> sloppy experiments with unusable logic over something
>> that does the job and has had no discoverable buffer overflows, ever.
>>
>>
>> On Fri, Oct 28, 2022 at 3:17 PM Joe Schaefer  wrote:
>>
>>> None of the patches to util.c include corresponding patches to any of
>>> the several layers of test suites involved in libapreq.
>>> It's starting to wear on our user's nerves.
>>>
>>> On Fri, Oct 28, 2022 at 3:04 PM  wrote:
>>>
 Long time fan, not a first time caller.



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



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



 Everything in the crufty, old apreq_header_attribute code I wrote was
 completely tossed and reimplemented.  Why?  We’re just racking up CVE’s,
 people are disabling the mfd parser altogether, and it no longer support
 common use cases that people now complain about because it supported cases
 in the wild that the new work does not.



 With the latest code coming out of p5p for Perl, there’s a whole new
 reason for excitement in httpd-land: the mod_perl2 + mpm_event combination
 is rock solid and screaming fast with HTTP/2.  The only reason I resubbed
 here is in the hopes of some synergy retaking these perl-related projects,
 since mod_perl2 is the only game in town for embedded interpreters in
 httpd2 (and no, lua is not the answer, it’s not thread safe either).





 Joe Schaefer, Ph.D.

 

 954.253.3732 

 SunStar Systems CMS  *- The Original
 Markdown JAM Stack**™*



>>>
>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> 
>>> 954.253.3732 
>>>
>>>
>>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> 
>> 954.253.3732 
>>
>>
>>
>
> --
> Eric Covener
> cove...@gmail.com
>


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

954.253.3732 

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

[Eric Covener]

Would you like to maintain it outside of httpd?

my +1 to drop the subproject and rip it from httpd trunk.

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

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

-- 
Eric Covener
cove...@gmail.com

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

[Joe Schaefer]

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


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

> What I'd like to see happen is util.c reverted back to 532620.  The
> current HEAD is unusable for many users, who are now stuck with the choice
> of rolling back to the 2.16 release and accepting the buffer overflows that
> come with it.
>
>
>
> On Fri, Oct 28, 2022 at 3:51 PM Joe Schaefer  wrote:
>
>> The function under scrutiny here is apreq_header_attribute. The only use
>> case for that function in a form-data
>> parsing library is to deal with the Content-Disposition header, which has
>> a very tight MIME spec that does not
>> involve rewriting the old code for a generic header attribute parser,
>> without anyone filing a bug report about the
>> original one.
>>
>> libapreq2 is an old, stable codebase. The Perl community likes it that
>> way. We think it's great when flaws are discovered,
>> which means patches are in order.  But it is not the right codebase for
>> sloppy experiments with unusable logic over something
>> that does the job and has had no discoverable buffer overflows, ever.
>>
>>
>> On Fri, Oct 28, 2022 at 3:17 PM Joe Schaefer  wrote:
>>
>>> None of the patches to util.c include corresponding patches to any of
>>> the several layers of test suites involved in libapreq.
>>> It's starting to wear on our user's nerves.
>>>
>>> On Fri, Oct 28, 2022 at 3:04 PM  wrote:
>>>
 Long time fan, not a first time caller.



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



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



 Everything in the crufty, old apreq_header_attribute code I wrote was
 completely tossed and reimplemented.  Why?  We’re just racking up CVE’s,
 people are disabling the mfd parser altogether, and it no longer support
 common use cases that people now complain about because it supported cases
 in the wild that the new work does not.



 With the latest code coming out of p5p for Perl, there’s a whole new
 reason for excitement in httpd-land: the mod_perl2 + mpm_event combination
 is rock solid and screaming fast with HTTP/2.  The only reason I resubbed
 here is in the hopes of some synergy retaking these perl-related projects,
 since mod_perl2 is the only game in town for embedded interpreters in
 httpd2 (and no, lua is not the answer, it’s not thread safe either).





 Joe Schaefer, Ph.D.

 

 954.253.3732 

 SunStar Systems CMS  *- The Original
 Markdown JAM Stack**™*



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

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

954.253.3732 

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

[Joe Schaefer]

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



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

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

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

954.253.3732 

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

[Joe Schaefer]

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

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


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

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

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

954.253.3732 

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

[Joe Schaefer]

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

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

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


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

954.253.3732