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 <j...@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 <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> > > > -- Eric Covener cove...@gmail.com
