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 <j...@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 <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> >> >> >> > > -- > 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>
