Simply put, 2.17 was a fraudulent release according to HTTPd's own rules for RM's. Under no circumstances may an RM unilaterally disable any component of the test suite without notifying the remainder of the PMC *on list*, because it is simply a deceptive practice for the rest of the group to have to behave as if the RM is an adversary to both the people expecting to vote on the candidate, and the downstream CPAN users who require the test suite to pass before installing the software.
Not only was this never corrected, nor formally addressed by the board, the RM actually failed *up* and became PMC chair. On Sun, Feb 18, 2024 at 4:42 PM Joe Schaefer <j...@sunstarsys.com> wrote: > Would you trust any of them at this point? > > I have a copy of svn trunk. I will never use anything they release, no > matter what they call it. > > 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 Sun, Feb 18, 2024 at 4:41 PM Mithun Bhattacharya <mit...@gmail.com> > wrote: > >> So it will be moved to retired I assume or are they going to break their >> own rules and purge it altogether? >> >> >> On Sun, Feb 18, 2024, 3:33 PM Joe Schaefer <j...@sunstarsys.com> wrote: >> >>> 2.18 will never be released. They are shutting down the project. >>> >>> 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 Sun, Feb 18, 2024 at 4:32 PM Mithun Bhattacharya <mit...@gmail.com> >>> wrote: >>> >>>> Could you clarify this - 2.17 has a critical bug and 2.18 is about to >>>> come out which doesn't have a good enough patch so how would trunk be any >>>> better? >>>> >>>> Also how is this passing make test or were the test cases modified to >>>> make the bug pass ? >>>> >>>> >>>> On Sun, Feb 18, 2024, 1:12 PM Joe Schaefer <j...@sunstarsys.com> wrote: >>>> >>>>> Trunk is the safe bet. >>>>> >>>>> 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 Sun, Feb 18, 2024 at 2:11 PM Mithun Bhattacharya <mit...@gmail.com> >>>>> wrote: >>>>> >>>>>> So is there a cleaner/saner version of libapreq2 or is the 2012 >>>>>> version better ? >>>>>> >>>>>> On Sun, Feb 18, 2024, 12:58 PM Joe Schaefer <j...@sunstarsys.com> >>>>>> wrote: >>>>>> >>>>>>> For the past 25 years, I have been the lead developer of the >>>>>>> libapreq2 subproject within the Apache HTTPd Server Parent Project. The >>>>>>> original idea of libapreq as a safe/performant HTML form and Cookie >>>>>>> parsing >>>>>>> library came out of a collaboration between Lincoln Stein and Doug >>>>>>> MacEachern in the late 90s. >>>>>>> >>>>>>> It was my vision back then to transform the library into a generic, >>>>>>> non-Perl related C library that would support language bindings from >>>>>>> other >>>>>>> programming languages, which is why I pushed for the project to be homes >>>>>>> under the HTTPd umbrella instead of the Apache-Perl project. >>>>>>> >>>>>>> While this vision was wildly successful, with language bindings >>>>>>> available for several languages like Perl, TCL, R, etc, ever since about >>>>>>> 2010 its proven tragic for the existing user community consisting of >>>>>>> all of >>>>>>> them, not just Perl. >>>>>>> >>>>>>> What happened? Philip Gollucci, a Perl/FreeBSD olleague of mine at >>>>>>> the time, started agitating that we promote the project to be released >>>>>>> from >>>>>>> inside the HTTPd server itself. What Philip didn’t know very well back >>>>>>> then >>>>>>> was how utterly vapid and territorial that team had become, which would >>>>>>> have meant having to collaborate with them directly on user-facing >>>>>>> decisions about the code base. >>>>>>> >>>>>>> In 2012, Philip got what he wanted and I stopped resisting, so he >>>>>>> forked the existing project and copied the C library components into >>>>>>> HTTPd >>>>>>> core. >>>>>>> >>>>>>> In 2016 I resigned from the Foundation en masse. You can guess the >>>>>>> reasons. >>>>>>> >>>>>>> In 2020 or so, Google’s Security Team took advantage of an alpha >>>>>>> release of httpd 2.5 by fuzzing its 8 year old copy of apreq. It found a >>>>>>> few hotspots that needed repair. >>>>>>> >>>>>>> Instead of having the courtesy of reaching out to me, or anyone else >>>>>>> involved in development of apreq, a junior engineer on the HTTPd team >>>>>>> went >>>>>>> about the business of “bug fixing” the vulnerabilities Google found. You >>>>>>> can see a record of his trial and error work in every release since >>>>>>> then. >>>>>>> >>>>>>> But the coup de grace was the 2022 release of 2.17, wherein the >>>>>>> rookie developer purposely introduced a fatal bug into the codebase, >>>>>>> breaking a fifteen year old regression test. >>>>>>> >>>>>>> If you are wondering how something with a broken regression test >>>>>>> winds up on CPAN, you’ll have to look into how RELENG is done in the >>>>>>> server >>>>>>> project. >>>>>>> >>>>>>> Long story short, they commented out the test and shipped it anyway, >>>>>>> and called it a Security Release that fixed a vulnerability every prior >>>>>>> release was susceptible to. >>>>>>> >>>>>>> Why do I care now? Because I’m the sucker users reach out to for >>>>>>> answers as a known subject matter expert. >>>>>>> >>>>>>> This sucks, but I’m sorry to tell you that my days wearing the >>>>>>> Superman cape at Apache ended 8 years ago. >>>>>>> >>>>>>> -- >>>>>>> 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> >>>>>>> >>>>>>> >>>>>>>
