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>