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 <j...@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 <j...@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 <cove...@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 <j...@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 <j...@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 <j...@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.
>>>>>>
>>>>>> <j...@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.
>>>>> <j...@sunstarsys.com>
>>>>> 954.253.3732 <//954.253.3732>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Joe Schaefer, Ph.D.
>>>> We only build what you need built.
>>>> <j...@sunstarsys.com>
>>>> 954.253.3732 <//954.253.3732>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Eric Covener
>>> cove...@gmail.com
>>>
>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> <j...@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <j...@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

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

Reply via email to