Thanks for the tip! It's actually pretty good news that the only thing google's fuzzer is complaining about is the very small piece of the puzzle. We just need to get it right this time.
On Sat, Oct 29, 2022 at 1:38 PM Greg Stein <gst...@gmail.com> wrote: > F/OSS is not about telling others how to write their code, Joe. You know > this. And it *definitely* is not about demanding they spend *their* time to > fix your pet issues. > > If you have a problem with the code, then supply a fix. Your dozen emails > are not fixing anything, and are certainly not endearing anybody to help > you. Be nice, if you want help. > > -g > > > On Sat, Oct 29, 2022 at 11:11 AM Joe Schaefer <j...@sunstarsys.com> wrote: > >> ...fell apart when Max asked you to release his patch to my screwup with >> the NPE, and instead of cutting a release >> with just that patch applied, you began the tragic process of dorking >> around with apreq_header_attribute() as well. >> >> Just pull all those hacks out of apreq/trunk, and release exactly what >> Max told you to release, and you will be good for another quiet decade of >> happy libapreq2 users. >> >> If you do not take this advice, at least for your own personal >> reputations, stop hacking the logic and start writing regression tests. >> An internet-grade mfd parser is only as good as its weakest link, and I >> just spent the past day telling you where that is. >> >> On Sat, Oct 29, 2022 at 12:06 PM Joe Schaefer <j...@sunstarsys.com> wrote: >> >>> All we need to do at this point is remember the basics of how to cut a >>> security bugfix release. Everything in libapreq >>> >>> 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>
