Look Eric, I gave you beta males an entire year to find an excuse for completely boning the modperl user community for no good reason, other than your precious egos were harmed while going though the motions for the past ten years with this project.
So far, the only thing to come of putting apreq inside httpd is that third party quality control teams put some elbow grease into fuzzing its various parsers and found a sore spot that you bland engineers felt put upon to fix. And so you botched that patch too, largely out of spite for the makework. There’s a reason the Dean Gaudet‘s of the development sector lost interest in hanging out with the weenie tot brigade people like Eric represent. It’s why I want out now too. Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features> <j...@sunstarsys.com> 954.253.3732 <//954.253.3732> On Wed, Feb 14, 2024 at 10:33 PM Joe Schaefer <j...@sunstarsys.com> wrote: > Bite me Eric. > > Next? > > > Joe Schaefer, Ph.D. > <https://sunstarsys.com/orion/features> > Orion - The Enterprise Jamstack Wiki > <https://sunstarsys.com/orion/features> > <j...@sunstarsys.com> > 954.253.3732 <//954.253.3732> > > > > > On Wed, Feb 14, 2024 at 10:25 PM Eric Covener <cove...@gmail.com> wrote: > >> On Wed, Feb 14, 2024 at 1:45 PM Joe Schaefer <j...@sunstarsys.com> wrote: >> > >> > Assuming Google hasn't found any more fuzzing vulnerabilities with >> apreq, we should call the subproject done after releasing it, rolling any >> new efforts into httpd's internal copy of the codebase for the next major >> release of httpd. >> > >> > Sound like a plan? I can get the ball rolling on the RM process >> assuming I still have working login (or can reacquire it via pw reset. >> >> I think another apreq release makes sense. >> >> But from the few relevant threads over the years (many on private >> lists), there seems to be little maintainer support for apreq much >> less apreq embedded in httpd. If there ever were a release branched >> from trunk, I don't think it's likely the embedded apreq would >> survive. I think it's a big consideration for what's done with the >> standalone tree. >> >
