Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Apache>
  3. Dev
1 2  View All
[libapreq2] nits to pick about the patches to util.c over the past few years
joe at sunstarsys
Oct 28, 2022, 12:04 PM
Post #1 of 45 (1411 views)
Permalink
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.

<joe@sunstarsys.com <mailto:joe@sunstarsys.com> >

954.253.3732 <tel://954.253.3732/>

SunStar Systems CMS <https://sunstarsys.com/CMS/> - The Original Markdown JAM Stack™

Attached Files:

Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
joe at sunstarsys
Oct 28, 2022, 12:17 PM
Post #2 of 45 (1410 views)
Permalink
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 <joe@sunstarsys.com> 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.
>
> <joe@sunstarsys.com>
>
> 954.253.3732 <//954.253.3732/>
>
> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
> Markdown JAM Stack**™*
>
>
>


--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
joe at sunstarsys
Oct 28, 2022, 12:51 PM
Post #3 of 45 (1410 views)
Permalink
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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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.
>>
>> <joe@sunstarsys.com>
>>
>> 954.253.3732 <//954.253.3732/>
>>
>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>> Markdown JAM Stack**™*
>>
>>
>>
>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
joe at sunstarsys
Oct 28, 2022, 1:06 PM
Post #4 of 45 (1410 views)
Permalink
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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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.
>>>
>>> <joe@sunstarsys.com>
>>>
>>> 954.253.3732 <//954.253.3732/>
>>>
>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>>> Markdown JAM Stack**™*
>>>
>>>
>>>
>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
joe at sunstarsys
Oct 28, 2022, 1:38 PM
Post #5 of 45 (1410 views)
Permalink
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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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.
>>>>
>>>> <joe@sunstarsys.com>
>>>>
>>>> 954.253.3732 <//954.253.3732/>
>>>>
>>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>>>> Markdown JAM Stack**™*
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> <joe@sunstarsys.com>
>>> 954.253.3732 <//954.253.3732>
>>>
>>>
>>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
covener at gmail
Oct 28, 2022, 1:49 PM
Post #6 of 45 (1410 views)
Permalink
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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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.
>>>
>>> <joe@sunstarsys.com>
>>>
>>> 954.253.3732 <//954.253.3732/>
>>>
>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>>> Markdown JAM Stack**™*
>>>
>>>
>>>
>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Eric Covener
covener@gmail.com
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
joe at sunstarsys
Oct 28, 2022, 1:51 PM
Post #7 of 45 (1410 views)
Permalink
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 <covener@gmail.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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.
>>>>
>>>> <joe@sunstarsys.com>
>>>>
>>>> 954.253.3732 <//954.253.3732/>
>>>>
>>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>>>> Markdown JAM Stack**™*
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> <joe@sunstarsys.com>
>>> 954.253.3732 <//954.253.3732>
>>>
>>>
>>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>>
>
> --
> Eric Covener
> covener@gmail.com
>


--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
joe at sunstarsys
Oct 28, 2022, 2:00 PM
Post #8 of 45 (1410 views)
Permalink
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 <joe@sunstarsys.com> 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 <covener@gmail.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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.
>>>>>
>>>>> <joe@sunstarsys.com>
>>>>>
>>>>> 954.253.3732 <//954.253.3732/>
>>>>>
>>>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>>>>> Markdown JAM Stack**™*
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Joe Schaefer, Ph.D.
>>>> We only build what you need built.
>>>> <joe@sunstarsys.com>
>>>> 954.253.3732 <//954.253.3732>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> <joe@sunstarsys.com>
>>> 954.253.3732 <//954.253.3732>
>>>
>>>
>>>
>>
>> --
>> Eric Covener
>> covener@gmail.com
>>
>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
joe at sunstarsys
Oct 28, 2022, 2:15 PM
Post #9 of 45 (1408 views)
Permalink
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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <covener@gmail.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com>
>>>> 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 <joe@sunstarsys.com> 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.
>>>>>>
>>>>>> <joe@sunstarsys.com>
>>>>>>
>>>>>> 954.253.3732 <//954.253.3732/>
>>>>>>
>>>>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>>>>>> Markdown JAM Stack**™*
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Joe Schaefer, Ph.D.
>>>>> We only build what you need built.
>>>>> <joe@sunstarsys.com>
>>>>> 954.253.3732 <//954.253.3732>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Joe Schaefer, Ph.D.
>>>> We only build what you need built.
>>>> <joe@sunstarsys.com>
>>>> 954.253.3732 <//954.253.3732>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Eric Covener
>>> covener@gmail.com
>>>
>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
covener at gmail
Oct 28, 2022, 2:23 PM
Post #10 of 45 (1408 views)
Permalink
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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <covener@gmail.com> 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 <joe@sunstarsys.com>
>>>> 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 <joe@sunstarsys.com>
>>>>> 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 <joe@sunstarsys.com> 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.
>>>>>>>
>>>>>>> <joe@sunstarsys.com>
>>>>>>>
>>>>>>> 954.253.3732 <//954.253.3732/>
>>>>>>>
>>>>>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>>>>>>> Markdown JAM Stack**™*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Joe Schaefer, Ph.D.
>>>>>> We only build what you need built.
>>>>>> <joe@sunstarsys.com>
>>>>>> 954.253.3732 <//954.253.3732>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Joe Schaefer, Ph.D.
>>>>> We only build what you need built.
>>>>> <joe@sunstarsys.com>
>>>>> 954.253.3732 <//954.253.3732>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Eric Covener
>>>> covener@gmail.com
>>>>
>>>
>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> <joe@sunstarsys.com>
>>> 954.253.3732 <//954.253.3732>
>>>
>>>
>>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Eric Covener
covener@gmail.com
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
joe at sunstarsys
Oct 28, 2022, 2:30 PM
Post #11 of 45 (1408 views)
Permalink
Just take this patch:
https://svn.apache.org/viewvc/httpd/apreq/trunk/library/t/util.c?r1=1124517&r2=1903497&pathrev=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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <covener@gmail.com> 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 <joe@sunstarsys.com>
>>>> 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 <joe@sunstarsys.com>
>>>>> 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 <joe@sunstarsys.com> 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.
>>>>>>>
>>>>>>> <joe@sunstarsys.com>
>>>>>>>
>>>>>>> 954.253.3732 <//954.253.3732/>
>>>>>>>
>>>>>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>>>>>>> Markdown JAM Stack**™*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Joe Schaefer, Ph.D.
>>>>>> We only build what you need built.
>>>>>> <joe@sunstarsys.com>
>>>>>> 954.253.3732 <//954.253.3732>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Joe Schaefer, Ph.D.
>>>>> We only build what you need built.
>>>>> <joe@sunstarsys.com>
>>>>> 954.253.3732 <//954.253.3732>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Eric Covener
>>>> covener@gmail.com
>>>>
>>>
>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> <joe@sunstarsys.com>
>>> 954.253.3732 <//954.253.3732>
>>>
>>>
>>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
joe at sunstarsys
Oct 28, 2022, 2:39 PM
Post #12 of 45 (1408 views)
Permalink
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 <covener@gmail.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <covener@gmail.com> 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 <joe@sunstarsys.com>
>>>>> 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 <joe@sunstarsys.com>
>>>>>> 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 <joe@sunstarsys.com> 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.
>>>>>>>>
>>>>>>>> <joe@sunstarsys.com>
>>>>>>>>
>>>>>>>> 954.253.3732 <//954.253.3732/>
>>>>>>>>
>>>>>>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>>>>>>>> Markdown JAM Stack**™*
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Joe Schaefer, Ph.D.
>>>>>>> We only build what you need built.
>>>>>>> <joe@sunstarsys.com>
>>>>>>> 954.253.3732 <//954.253.3732>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Joe Schaefer, Ph.D.
>>>>>> We only build what you need built.
>>>>>> <joe@sunstarsys.com>
>>>>>> 954.253.3732 <//954.253.3732>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Eric Covener
>>>>> covener@gmail.com
>>>>>
>>>>
>>>>
>>>> --
>>>> Joe Schaefer, Ph.D.
>>>> We only build what you need built.
>>>> <joe@sunstarsys.com>
>>>> 954.253.3732 <//954.253.3732>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> <joe@sunstarsys.com>
>>> 954.253.3732 <//954.253.3732>
>>>
>>>
>>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>>
>
> --
> Eric Covener
> covener@gmail.com
>


--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
joe at sunstarsys
Oct 28, 2022, 3:56 PM
Post #13 of 45 (1408 views)
Permalink
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 <joe@sunstarsys.com> 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 <covener@gmail.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com>
>>>> 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 <covener@gmail.com>
>>>>> 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 <joe@sunstarsys.com>
>>>>>> 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 <joe@sunstarsys.com>
>>>>>>> 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 <joe@sunstarsys.com> 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.
>>>>>>>>>
>>>>>>>>> <joe@sunstarsys.com>
>>>>>>>>>
>>>>>>>>> 954.253.3732 <//954.253.3732/>
>>>>>>>>>
>>>>>>>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>>>>>>>>> Markdown JAM Stack**™*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Joe Schaefer, Ph.D.
>>>>>>>> We only build what you need built.
>>>>>>>> <joe@sunstarsys.com>
>>>>>>>> 954.253.3732 <//954.253.3732>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Joe Schaefer, Ph.D.
>>>>>>> We only build what you need built.
>>>>>>> <joe@sunstarsys.com>
>>>>>>> 954.253.3732 <//954.253.3732>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Eric Covener
>>>>>> covener@gmail.com
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Joe Schaefer, Ph.D.
>>>>> We only build what you need built.
>>>>> <joe@sunstarsys.com>
>>>>> 954.253.3732 <//954.253.3732>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Joe Schaefer, Ph.D.
>>>> We only build what you need built.
>>>> <joe@sunstarsys.com>
>>>> 954.253.3732 <//954.253.3732>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> <joe@sunstarsys.com>
>>> 954.253.3732 <//954.253.3732>
>>>
>>>
>>>
>>
>> --
>> Eric Covener
>> covener@gmail.com
>>
>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
joe at sunstarsys
Oct 28, 2022, 5:59 PM
Post #14 of 45 (1406 views)
Permalink
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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <covener@gmail.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com>
>>>> 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 <joe@sunstarsys.com>
>>>>> 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 <covener@gmail.com>
>>>>>> 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 <joe@sunstarsys.com>
>>>>>>> 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 <joe@sunstarsys.com>
>>>>>>>> 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 <joe@sunstarsys.com> 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.
>>>>>>>>>>
>>>>>>>>>> <joe@sunstarsys.com>
>>>>>>>>>>
>>>>>>>>>> 954.253.3732 <//954.253.3732/>
>>>>>>>>>>
>>>>>>>>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The
>>>>>>>>>> Original Markdown JAM Stack**™*
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Joe Schaefer, Ph.D.
>>>>>>>>> We only build what you need built.
>>>>>>>>> <joe@sunstarsys.com>
>>>>>>>>> 954.253.3732 <//954.253.3732>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Joe Schaefer, Ph.D.
>>>>>>>> We only build what you need built.
>>>>>>>> <joe@sunstarsys.com>
>>>>>>>> 954.253.3732 <//954.253.3732>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Eric Covener
>>>>>>> covener@gmail.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Joe Schaefer, Ph.D.
>>>>>> We only build what you need built.
>>>>>> <joe@sunstarsys.com>
>>>>>> 954.253.3732 <//954.253.3732>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Joe Schaefer, Ph.D.
>>>>> We only build what you need built.
>>>>> <joe@sunstarsys.com>
>>>>> 954.253.3732 <//954.253.3732>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Joe Schaefer, Ph.D.
>>>> We only build what you need built.
>>>> <joe@sunstarsys.com>
>>>> 954.253.3732 <//954.253.3732>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Eric Covener
>>> covener@gmail.com
>>>
>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
> --
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
joe at sunstarsys
Oct 28, 2022, 6:56 PM
Post #15 of 45 (1404 views)
Permalink
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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <covener@gmail.com> 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 <joe@sunstarsys.com>
>>>> 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 <joe@sunstarsys.com>
>>>>> 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 <joe@sunstarsys.com>
>>>>>> 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 <covener@gmail.com>
>>>>>>> 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 <joe@sunstarsys.com>
>>>>>>>> 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 <joe@sunstarsys.com>
>>>>>>>>> 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 <joe@sunstarsys.com> 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.
>>>>>>>>>>>
>>>>>>>>>>> <joe@sunstarsys.com>
>>>>>>>>>>>
>>>>>>>>>>> 954.253.3732 <//954.253.3732/>
>>>>>>>>>>>
>>>>>>>>>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The
>>>>>>>>>>> Original Markdown JAM Stack**™*
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Joe Schaefer, Ph.D.
>>>>>>>>>> We only build what you need built.
>>>>>>>>>> <joe@sunstarsys.com>
>>>>>>>>>> 954.253.3732 <//954.253.3732>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Joe Schaefer, Ph.D.
>>>>>>>>> We only build what you need built.
>>>>>>>>> <joe@sunstarsys.com>
>>>>>>>>> 954.253.3732 <//954.253.3732>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Eric Covener
>>>>>>>> covener@gmail.com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Joe Schaefer, Ph.D.
>>>>>>> We only build what you need built.
>>>>>>> <joe@sunstarsys.com>
>>>>>>> 954.253.3732 <//954.253.3732>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Joe Schaefer, Ph.D.
>>>>>> We only build what you need built.
>>>>>> <joe@sunstarsys.com>
>>>>>> 954.253.3732 <//954.253.3732>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Joe Schaefer, Ph.D.
>>>>> We only build what you need built.
>>>>> <joe@sunstarsys.com>
>>>>> 954.253.3732 <//954.253.3732>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Eric Covener
>>>> covener@gmail.com
>>>>
>>>
>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> <joe@sunstarsys.com>
>>> 954.253.3732 <//954.253.3732>
>>>
>>>
>>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
joe at sunstarsys
Oct 29, 2022, 9:06 AM
Post #16 of 45 (1402 views)
Permalink
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 <joe@sunstarsys.com> 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.
>
> <joe@sunstarsys.com>
>
> 954.253.3732 <//954.253.3732/>
>
> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
> Markdown JAM Stack**™*
>
>
>


--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
joe at sunstarsys
Oct 29, 2022, 9:11 AM
Post #17 of 45 (1402 views)
Permalink
...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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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.
>>
>> <joe@sunstarsys.com>
>>
>> 954.253.3732 <//954.253.3732/>
>>
>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>> Markdown JAM Stack**™*
>>
>>
>>
>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
ylavic.dev at gmail
Oct 29, 2022, 9:59 AM
Post #18 of 45 (1402 views)
Permalink
Hi Joe,

here comes the "goofer".

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

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

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

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

>
> 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 [ In reply to ]
joe at sunstarsys
Oct 29, 2022, 10:16 AM
Post #19 of 45 (1402 views)
Permalink
On Sat, Oct 29, 2022 at 1:00 PM Yann Ylavic <ylavic.dev@gmail.com> wrote:

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


Fair enough.


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

Then lets deal with it by adding more tests.


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


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


--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
gstein at gmail
Oct 29, 2022, 10:38 AM
Post #20 of 45 (1402 views)
Permalink
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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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.
>>>
>>> <joe@sunstarsys.com>
>>>
>>> 954.253.3732 <//954.253.3732/>
>>>
>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>>> Markdown JAM Stack**™*
>>>
>>>
>>>
>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
joe at sunstarsys
Oct 29, 2022, 10:47 AM
Post #21 of 45 (1402 views)
Permalink
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 <gstein@gmail.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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.
>>>>
>>>> <joe@sunstarsys.com>
>>>>
>>>> 954.253.3732 <//954.253.3732/>
>>>>
>>>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original
>>>> Markdown JAM Stack**™*
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> <joe@sunstarsys.com>
>>> 954.253.3732 <//954.253.3732>
>>>
>>>
>>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
joe at sunstarsys
Oct 29, 2022, 11:12 AM
Post #22 of 45 (1402 views)
Permalink
On Sat, Oct 29, 2022 at 1:16 PM Joe Schaefer <joe@sunstarsys.com> wrote:

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

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


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

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

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

static void test_brigade_concat(dAT, void *ctx)
@@ -315,7 +320,7 @@
{ dT(test_join, 0) },
{ dT(test_brigade_fwrite, 0) },
{ dT(test_file_mktemp, 0) },
- { dT(test_header_attribute, 6) },
+ { dT(test_header_attribute, 8) },
{ dT(test_brigade_concat, 0) },
};
--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
joe at sunstarsys
Oct 29, 2022, 11:47 AM
Post #23 of 45 (1402 views)
Permalink
Curiously, this doesn't seem to present any problems for
apreq_header_attribute in trunk/HEAD. A good thing.

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

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

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

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
joe at sunstarsys
Oct 29, 2022, 5:36 PM
Post #24 of 45 (1400 views)
Permalink
Found the problem: it's just a misunderstanding about what is admissible in
a successful file upload widget.
If someone doesn't add a file to the upload widget, it is still a
successful control and should be processed as such on the server.
In this case, just like with opera, the filename attribute will be present,
but set to an empty double-quoted string.

Here's my patchset, enjoy.









On Sat, Oct 29, 2022 at 2:47 PM Joe Schaefer <joe@sunstarsys.com> wrote:

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

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

Attached Files:

Re: [libapreq2] nits to pick about the patches to util.c over the past few years [ In reply to ]
joe at sunstarsys
Oct 29, 2022, 6:15 PM
Post #25 of 45 (1398 views)
Permalink
Of course, I don’t know how to advise you regarding the security aspects,
since you’re doing what you thought was the right thing to do and put the
mfd parser into an error state instead of leaving well enough alone. But
basically libapreq2 users get annoyed when the parser breaks on valid
input, and may get antsy when their server goes bonkers because they aren’t
in the habit of doing error handling on this condition.

On Sat, Oct 29, 2022 at 8:36 PM Joe Schaefer <joe@sunstarsys.com> wrote:

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

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal