There’s likely another CVE to add to the matrix revolving around the way the current code deals with an empty file name attribute, given the bizarre behavior of the rest of the code that runs after.
On Fri, Oct 28, 2022 at 6:56 PM Joe Schaefer <j...@sunstarsys.com> wrote: > There simply is no usable libapreq2 release that's not either riddled with > CVE's, or actually supports every common browser that submits form-data > online. > That wasn't apreq developer's doing, it was httpd's. All you've been > doing is pushing alpha quality apreq_header_attribute implementations that > you wouldn't dream of shipping in httpd3 GA, > and letting libapreq users be your QA department instead of writing tests > to demonstrate your bona-fides to tackle this problem appropriately in any > GA software project. > There's a lot of ways of handling the discrepancy between the code in > httpd/trunk and the code in apreq/trunk (our release branch) that doesn't > involve this nonsense. > > You can do better, because I've seen it. All anyone can ask is for better > QA in GA releases in a project that has only seen one dud after the next > for three plus years. > It will make httpd3 better in the future if you do. > > On Fri, Oct 28, 2022 at 5:39 PM Joe Schaefer <j...@sunstarsys.com> wrote: > >> 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> >> >> >> > > -- > 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>
