At least a DoS grade CVE, depending on how users call into the upload API (server hangs). Are we having a sufficient amount of fun dorking with util.c in libapreq2 production?
On Fri, Oct 28, 2022 at 8:59 PM Joe Schaefer <j...@sunstarsys.com> wrote: > 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> > > > -- Joe Schaefer, Ph.D. We only build what you need built. <j...@sunstarsys.com> 954.253.3732 <//954.253.3732>
