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