Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
like this guy does: https://stackoverflow.com/questions/60281807/get-post-request-body-and-decode-using-mod-lua-apache-http-2-4 Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features> 954.253.3732 On

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
Stupid shit like this is everyone's problem: https://www.tenable.com/plugins/nessus/161454 Hating me for solving it cleanly is par for the course for the current httpd committer community. On Thu, Feb 15, 2024 at 8:41 PM Joe Schaefer wrote: > Back in the day, httpd was a celebra

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
15, 2024 at 8:20 PM Joe Schaefer wrote: > The proof is in the pudding, as it were. > > There's prima facia evidence in this very thread that he lied about ever > running the test suite for apreq, because Joe wouldn't have had to patch it > for him 8 months later had he ever bother

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
The proof is in the pudding, as it were. There's prima facia evidence in this very thread that he lied about ever running the test suite for apreq, because Joe wouldn't have had to patch it for him 8 months later had he ever bothered in the first place. But when everyone around you is no better

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
The nightmare scenario is when you try to support HTTP/3 when you can’t even support an HTML form parser. Have an appropriate amount of fun. Popcorn is popping. Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
are on GitHub. And yet it persists. It also is why you guinea pig your user base instead of respecting them, because you aren’t a part of that community any more. And it shows with each new dud delivered to the apreq user base over the past decade. So let’s end this fiasco ASAP. Joe Schaefer

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
Keep your tone policing off list wise guy. If you have something of substance to offer to your colleagues other than defensive posturing, let’s have it. Like all these vacuous bug reports missing from the issue tracker about apreq, that you rumor mongers like to scare people with. Joe Schaefer

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
with each other again over it. Thanks Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features> 954.253.3732 On Thu, Feb 15, 2024 at 5:17 PM Eric Covener wrote: > On Wed, Feb 14, 2024 at 11:57 

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
Joe Schaefer wrote: > You mean the 2.17 release, where Joe Orton actually patched the test suite > out of your coercion? > > Great engineering. > > http://svn.apache.org/viewvc?view=revision=1903489 > > > Joe Schaefer, Ph.D. > <https://sunstarsys.com/orion/features&g

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
You mean the 2.17 release, where Joe Orton actually patched the test suite out of your coercion? Great engineering. http://svn.apache.org/viewvc?view=revision=1903489 Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.

Re: release apreq 2.18 and mothball the project

2024-02-14 Thread Joe Schaefer
Twenty years in core, with one bug to fix. And you couldn’t even manage without three different botched releases. Please, for the love of its users, stop fixing it. Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.

Re: release apreq 2.18 and mothball the project

2024-02-14 Thread Joe Schaefer
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> 954.253.3732

Re: release apreq 2.18 and mothball the project

2024-02-14 Thread Joe Schaefer
Bite me Eric. Next? Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features> 954.253.3732 On Wed, Feb 14, 2024 at 10:25 PM Eric Covener wrote: > On Wed, Feb 14, 2024 at 1:45 PM Joe

release apreq 2.18 and mothball the project

2024-02-14 Thread Joe Schaefer
assuming I still have working login (or can reacquire it via pw reset. -- Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features> 954.253.3732

Re: PR #363

2024-01-24 Thread Joe Schaefer
With GFM, each line break separates paragraphs. Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features> 954.253.3732 On Wed, Jan 24, 2024 at 11:01 AM Yann Ylavic wrote: > On Wed, Jan 24, 2024

Re: [VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58

2023-10-17 Thread Joe Schaefer
Steve Hay was a great resource once upon a time ago, but meh, you can't draw blood from a stone forever. On Tue, Oct 17, 2023 at 12:32 PM Steffen wrote: > For me still -1. > > > Op 17 okt 2023 om 18:18 heeft Stefan Eissing via dev < > dev@httpd.apache.org> het volgende geschreven: > > > > Just

Re: Please support/enable https by default in the Apache web sever.

2023-09-30 Thread Joe Schaefer
It is insane to ask this project to cater to the interests of 10 people who are so PKI illiterate, the PMC needs to put the rest of the user base at risk just to accommodate them. Certs require mandatory user serviceable parts. There is no meaningful way to provide a default. Thanks. On Sat,

Re: Time for a new libapreq2 release?

2023-08-28 Thread Joe Schaefer
; list (which also implies receiving future > emails to that list). > > > On Mon, Aug 28, 2023 at 3:52 PM Joe Schaefer wrote: > >> No objection. Happy to Tag and roll of my account is made available >> somehow. >> >> On Mon, Aug 28, 2023 at 4:50 PM Greg Stein

Re: Time for a new libapreq2 release?

2023-08-28 Thread Joe Schaefer
> went, but as a PMC member of httpd you should have commit. We can fix that. > > So should we fix this up, so you can walk through a libapreq2 release? > > Cheers, > -g > [1] https://whimsy.apache.org/roster/committer/joes > > > On Mon, Aug 28, 2023 at 8:43 AM Joe Schaefer wrot

Re: Time for a new libapreq2 release?

2023-08-28 Thread Joe Schaefer
Because my account no longer exists? On Mon, Aug 28, 2023 at 1:43 AM Greg Stein wrote: > you're on the PMC. Why don't you do the tag ? > > On Sun, Aug 27, 2023 at 4:31 PM Joe Schaefer wrote: > >> Seems like it’s been a year since the last release, which means it’s time

Time for a new libapreq2 release?

2023-08-27 Thread Joe Schaefer
Seems like it’s been a year since the last release, which means it’s time for good people to take another try at releasing something nondefective. Here to help with the quality control this time around. -- Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Ente

Re: mod_wasm: Contributing Upstream to Apache

2023-07-07 Thread Joe Schaefer
imited > interfaces to the Wasm binary to perform such actions. So yes, we believe > your proposal of getting the apreq_* (ARP table-based) interfaces exposed > as read-only data structures is doable and useful. > > Cheers! > > > > *De: *Joe Schaefer > *Fecha: *miérc

Re: mod_wasm: Contributing Upstream to Apache

2023-07-04 Thread Joe Schaefer
can always configure apreq’s input filter to activate on the protocol filter chain before wasm activates. That way other modules still can access form input without breaking the Wasm app. On Tue, Jul 4, 2023 at 10:48 PM Joe Schaefer wrote: > The more of the API you expose, the less va

Re: mod_wasm: Contributing Upstream to Apache

2023-07-04 Thread Joe Schaefer
The more of the API you expose, the less value the sandbox has to end users. For Webapps, easy read/search / write/ iterate is essential. But also form data; which apreq stores in readonly apr tables. Joe Schaefer, Ph.D +1 (954) 253-3732 SunStar Systems, Inc. Orion - The Enterprise Jamstack

Re: libapreq 2.17 POST upload with empty filename parameter

2023-07-04 Thread Joe Schaefer
2.17 was a dud security release. Use trunk Joe Schaefer, Ph.D +1 (954) 253-3732 SunStar Systems, Inc. Orion - The Enterprise Jamstack Wiki From: Raymond Field via dev Sent: Tuesday, July 4, 2023 7:36:33 AM To: dev@httpd.apache.org Subject: libapreq 2.17 POST

Re: mod_wasm: Contributing Upstream to Apache

2023-06-01 Thread Joe Schaefer
Huge fan, love that you are receptive to my feedback. If you get to the point where the apreq_* (APR table-based) interfaces in trunk can be exposed as read-only data structures in mod_wasm as an optional API for power httpd users that like the sandboxed functionality you get OOTB, that would

Re: Apache2 chroot problem: towards a solution

2023-05-18 Thread Joe Schaefer
chroot() function is not a public function. It is an > internal function that is used by the Apache source code. As such, it is > not included in the public release of the Apache source code. > > I am not sure if there could be a module that would solve this issue, and > I'm not sure if

Re: [VOTE] Switch read/write repository from Subversion to Git

2023-05-10 Thread Joe Schaefer
I wish more Apache projects reach maintenance mode as part of their maturity model. It’s good to complete your mission instead of always digging deeper holes. Joe Schaefer, Ph.D +1 (954) 253-3732 SunStar Systems, Inc. Orion - The Enterprise Jamstack Wiki From

Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))

2023-04-25 Thread Joe Schaefer
Get over the heartache and brand loyalty and get on rw git. Github isn't the only game in town anymore for git hosting, so don't feel trapped by infra just because it's all they've got in the tank. On Tue, Apr 25, 2023 at 2:07 PM Eric Covener wrote: > On Tue, Apr 25, 2023 at 2:45 AM Ruediger

Re: CPU affinity request

2023-02-09 Thread Joe Schaefer
Nice proof of concept, but the code needs a serious porting effort to non-Linux platforms as well, and they’re all quirky in their own ways about this featureset. Doable tho. Joe Schaefer, Ph.D +1 (954) 253-3732 SunStar Systems, Inc. Orion - The Enterprise Jamstack Wiki

Re: Re: mod_wasm: Contributing Upstream to Apache

2023-01-27 Thread Joe Schaefer
Part of the really cool things you'd like to have as an app-server author that knows the APR/APU/HTTPd runtime are subrequests, including the portions that interact with the filter API. I'm always writing home-grown app-specific SSI-ish filters via mod_perl to process application pages as

Re: mod_wasm: Contributing Upstream to Apache

2023-01-27 Thread Joe Schaefer
Looking over the WASM Roadmap, it appears that they have a plan for multithreading within a single target language. That would allow you to fully support every silly GIL-addled language runtime out there, which would be very compelling. On Fri, Jan 27, 2023 at 1:33 PM Joe Schaefer wrote

Re: mod_wasm: Contributing Upstream to Apache

2023-01-27 Thread Joe Schaefer
A native interface outside of CGI compat for apreq would be a killer new feature, because it really finishes our vision for apreq as the one-HTML-spec-parser for all native apps, regardless of language choice. Of course this would be a new opt-in feature for target languages to take advantage of,

Re: mod_wasm: Contributing Upstream to Apache

2023-01-25 Thread Joe Schaefer
Still, the idea is wicked cool if mod_wasm really can isolate the Python, PHP, etc targets onto individual POSIX threads. Very exciting stuff for HTTP/2 Webapps. On Wed, Jan 25, 2023 at 4:31 AM Joe Schaefer wrote: > Looked at the PR- the IO is pretty primitive (no streaming anywh

Re: mod_wasm: Contributing Upstream to Apache

2023-01-25 Thread Joe Schaefer
Looked at the PR- the IO is pretty primitive (no streaming anywhere). Probably not fatal for Webapps, but it could use some better relations with the filter stack and bucket brigades. Joe Schaefer, Ph.D +1 (954) 253-3732 SunStar Systems, Inc. Orion - The Enterprise Jamstack Wiki

Re: mod_wasm: Contributing Upstream to Apache

2023-01-24 Thread Joe Schaefer
Would be great to marry it to apreq, too. On Tue, Jan 24, 2023 at 4:04 PM Joe Schaefer wrote: > It is impossible to run mod_h2 without it or similar. > > On Tue, Jan 24, 2023 at 3:37 PM Eric Covener wrote: > >> > We are still very interested in contributing this module up

Re: mod_wasm: Contributing Upstream to Apache

2023-01-24 Thread Joe Schaefer
It is impossible to run mod_h2 without it or similar. On Tue, Jan 24, 2023 at 3:37 PM Eric Covener wrote: > > We are still very interested in contributing this module upstream and > helping to maintain it. Please, let us know what improvements or changes > would be needed for it to be

Re: CVE-2022-22728: libapreq2: libapreq2 multipart form parse memory corruption

2023-01-02 Thread Joe Schaefer
2.17 is a dud. What’s in trunk works fine though. Joe Schaefer, Ph.D +1 (954) 253-3732 SunStar Systems, Inc. Orion - The Enterprise Jamstack Wiki From: enge...@gsuite.cloud.apache.org on behalf of Apache Security Team Sent: Monday, January 2, 2023 7:30:43 AM

Re: mod_wasm: Contributing Upstream to Apache

2022-11-28 Thread Joe Schaefer
iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=riwxB9vHMxT%2ByvYzGUXBXtgqMi%2B9%2BRVb1zUZSaTxTHE%3D=0> > > > > In terms of the actual contribution, please find a patch attached. We > tried to follow all existing conventions in terms of autoconf/automake, > providing module

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-11-05 Thread Joe Schaefer
Last patch: this one includes autoconf/automake repairs as well. On Fri, Nov 4, 2022 at 9:02 PM Joe Schaefer wrote: > Sometime before end of year, perhaps I can upgrade apreq's autotool deps > to something Ubuntu 22 can handle, > for the purpose of dockerizing a build environment for

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-11-04 Thread Joe Schaefer
a substantial difference in the quality of the development effort for apreq, even in httpd's trunk. On Fri, Nov 4, 2022 at 3:40 PM Joe Schaefer wrote: > One of these tests actually reported a problem with the "whimsical" patch > under consideration, Yann. > But instead of confronting

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-11-04 Thread Joe Schaefer
s, positively document those behaviors in the test suite, just like > your predecessors did. > Let's not make what happened with 2.17 a new status quo for your efforts. > > -Original Message- > From: Yann Ylavic > Sent: Wednesday, November 2, 2022 9:47 AM > To: dev@htt

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-11-04 Thread Joe Schaefer
Better version (backs out most of an incorrect prior change). On Fri, Nov 4, 2022 at 11:38 AM Joe Schaefer wrote: > Please add this additional regression test (for the mfd parser with empty > parts). > > > On Fri, Nov 4, 2022 at 11:12 AM Joe Schaefer wrote: > >> What's

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-11-04 Thread Joe Schaefer
Please add this additional regression test (for the mfd parser with empty parts). On Fri, Nov 4, 2022 at 11:12 AM Joe Schaefer wrote: > What's in HEAD as of now looks promising. I'll be happy to dogfood this > once we're in the candidacy stage. > The point of having apreq in trunk i

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-11-04 Thread Joe Schaefer
, lean on me for whatever peer review is missing from the normal release cycles for libapreq2 as you see fit. I can't promise how long you have my attention, but for the next few releases I'll try to participate in the vetting process. On Wed, Nov 2, 2022 at 10:22 AM Joe Schaefer wrote: > >

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-11-02 Thread Joe Schaefer
Get Outlook for iOS<https://aka.ms/o0ukef> From: Yann Ylavic Sent: Wednesday, November 2, 2022 9:47 AM To: dev@httpd.apache.org Cc: Joe Schaefer Subject: Re: [libapreq2] nits to pick about the patches to util.c over the past few years On Mon, Oct 31

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-31 Thread Joe Schaefer
a lot less painful to get my input in advance than after the fact. On Mon, Oct 31, 2022 at 1:56 PM Joe Schaefer wrote: > With regard to the faulty patch this revolves around: > https://svn.apache.org/viewvc?view=revision=1895107 > I do not expect you to know the specs, know the code,

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-31 Thread Joe Schaefer
, unmotivated patches are not appropriate in maintenance releases. On Mon, Oct 31, 2022 at 12:58 PM Joe Schaefer wrote: > This stuff was written for an RFC era of the mid 2000s, and a lot of the > uncertainties around industry direction have been clarified in the years > since then, par

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-31 Thread Joe Schaefer
then. If anything should be radically refactored and simplified, start there. On Mon, Oct 31, 2022 at 12:36 PM Joe Schaefer wrote: > > > Get Outlook for iOS <https://aka.ms/o0ukef> > -- > *From:* Ruediger Pluem > *Sent:* Monday, October 31, 2

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-31 Thread Joe Schaefer
Get Outlook for iOS<https://aka.ms/o0ukef> From: Ruediger Pluem Sent: Monday, October 31, 2022 12:21 PM To: dev@httpd.apache.org Subject: Re: [libapreq2] nits to pick about the patches to util.c over the past few years On 10/30/22 4:28 PM, Joe Sc

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-31 Thread Joe Schaefer
On Sun, Oct 30, 2022 at 12:09:02AM -0400, Joe Schaefer wrote: > Forgive me for summarizing, but I didn’t come here expecting help, much > less collaboration on a solution. I came here expecting to be scolded for > having the temerity to critique the quality of the patch sets you’ve been >

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-30 Thread Joe Schaefer
kef> From: Joe Schaefer Sent: Sunday, October 30, 2022 12:09:02 AM To: dev@httpd.apache.org Subject: Re: [libapreq2] nits to pick about the patches to util.c over the past few years Forgive me for summarizing, but I didn’t come here expecting help, much less collabo

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-29 Thread Joe Schaefer
in return other than some measure of respect for the effort involved. On Sat, Oct 29, 2022 at 9:59 PM Joe Schaefer wrote: > Missed one. The patch that introduced these changes was revision=1895107. > > > > On Sat, Oct 29, 2022 at 9:15 PM Joe Schaefer wrote: > >> Of

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-29 Thread Joe Schaefer
Missed one. The patch that introduced these changes was revision=1895107. On Sat, Oct 29, 2022 at 9:15 PM Joe Schaefer wrote: > Of course, I don’t know how to advise you regarding the security aspects, > since you’re doing what you thought was the right thing to do and put the > m

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-29 Thread Joe Schaefer
, and may get antsy when their server goes bonkers because they aren’t in the habit of doing error handling on this condition. On Sat, Oct 29, 2022 at 8:36 PM Joe Schaefer wrote: > Found the problem: it's just a misunderstanding about what is admissible > in a successful file upload

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-29 Thread Joe Schaefer
attribute will be present, but set to an empty double-quoted string. Here's my patchset, enjoy. On Sat, Oct 29, 2022 at 2:47 PM Joe Schaefer wrote: > Curiously, this doesn't seem to present any problems for > apreq_header_attribute in trunk/HEAD. A good thing. > > That means we may

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-29 Thread Joe Schaefer
Curiously, this doesn't seem to present any problems for apreq_header_attribute in trunk/HEAD. A good thing. That means we may need to look more closely at r1903484 in glue/perl. On Sat, Oct 29, 2022 at 2:12 PM Joe Schaefer wrote: > > On Sat, Oct 29, 2022 at 1:16 PM Joe Schaefer

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-29 Thread Joe Schaefer
On Sat, Oct 29, 2022 at 1:16 PM Joe Schaefer wrote: > > > On Sat, Oct 29, 2022 at 1:00 PM Yann Ylavic wrote: > >> Hi Joe, >> >> here comes the "goofer". >> >> On Fri, Oct 28, 2022 at 9:05 PM wrote: >> > >> > Long time fan,

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-29 Thread Joe Schaefer
Be nice, if you want help. > > -g > > > On Sat, Oct 29, 2022 at 11:11 AM Joe Schaefer 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 a

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-29 Thread Joe Schaefer
ing 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). > > Synergy! What a great intro.. > > > Regards; > Yann. > > [1] https://rt.cpan.org/Public/Bug/Display.html?id=144470 > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-29 Thread Joe Schaefer
link, and I just spent the past day telling you where that is. On Sat, Oct 29, 2022 at 12:06 PM Joe Schaefer 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 wrot

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-29 Thread Joe Schaefer
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. > > > > 954.253.3732 > > SunStar Sy

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-28 Thread Joe Schaefer
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 wrote: > There’s likely another CVE to add to the matrix revolving aro

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-28 Thread Joe Schaefer
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 wrote: > There simply is no usable libapr

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-28 Thread Joe Schaefer
if you do. On Fri, Oct 28, 2022 at 5:39 PM Joe Schaefer 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 wrote: > >> If it's the same i

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-28 Thread Joe Schaefer
ething constructive (like a test) there. > > On Fri, Oct 28, 2022 at 5:15 PM Joe Schaefer 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 wit

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-28 Thread Joe Schaefer
tree) that plays into your current needs for this functionality going forward. On Fri, Oct 28, 2022 at 5:15 PM Joe Schaefer 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

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-28 Thread Joe Schaefer
Joe Schaefer 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,

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-28 Thread Joe Schaefer
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 wrote

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-28 Thread Joe Schaefer
overed, >> 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

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-28 Thread Joe Schaefer
The good news is that I haven't seen this much buzz about apreq in the CPAN bug tracker in 15 years, so take the groaning with a grain of salt. On Fri, Oct 28, 2022 at 4:06 PM Joe Schaefer wrote: > What I'd like to see happen is util.c reverted back to 532620. The > current HEAD is un

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-28 Thread Joe Schaefer
What I'd like to see happen is util.c reverted back to 532620. The current HEAD is unusable for many users, who are now stuck with the choice of rolling back to the 2.16 release and accepting the buffer overflows that come with it. On Fri, Oct 28, 2022 at 3:51 PM Joe Schaefer wrote

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-28 Thread Joe Schaefer
something that does the job and has had no discoverable buffer overflows, ever. On Fri, Oct 28, 2022 at 3:17 PM Joe Schaefer 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 o

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

2022-10-28 Thread Joe Schaefer
son 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

Re: Was there any concrete decision on apreq?

2015-03-08 Thread Joe Schaefer
apreq is really both Graham, a httpd module and a library.But what I'd like to see is the apreq stuff in the server'score put into a separate library and have either httpd orthe apreq module link to it. Unfortunately the existing build system for apreq is automakebased, and I don't have much

Re: [VOTE] Release httpd 2.2.27 as GA?

2014-03-26 Thread Joe Schaefer
What is the specific issue Bill- afaict everything looks fine to me. On Wednesday, March 26, 2014 6:17 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On Mon, 17 Mar 2014 05:40:19 -0500 William A. Rowe Jr. wmr...@gmail.com wrote: I've been running behind too... But expect to have

Re: chunked trailers input filter processing by ap_http_filter should be documented

2013-02-12 Thread Joe Schaefer
trailers input filter processing by ap_http_filter should be documented On Sun, 10 Feb 2013 08:25:35 -0800 (PST) Joe Schaefer joe_schae...@yahoo.com wrote: Here's a sledgehammer patch to ap_rgetline_core() to replace r-input_filters with r-proto_input_filters. This would still mean protocol filters

INSERT_BEFORE logic backwards on input filters

2013-02-10 Thread Joe Schaefer
Here is the INSERT_BEFORE macro in util_filter.c: #define INSERT_BEFORE(f, before_this) ((before_this) == NULL \    || (before_this)-frec-ftype (f)-frec-ftype \    || (before_this)-r != (f)-r) While it does the right thing for output filters,

chunked trailers input filter processing by ap_http_filter should be documented

2013-02-10 Thread Joe Schaefer
So ap_http_filter winds up calling ap_get_mime_headers once it recognizes that the request body has finished, to process the trailing headers on chunked requests. This is actually a strange thing to do, because it means ap_http_filter winds up calling ap_get_brigade on r-input_filters with

Re: chunked trailers input filter processing by ap_http_filter should be documented

2013-02-10 Thread Joe Schaefer
; From: Joe Schaefer joe_schae...@yahoo.com To: dev@httpd.apache.org dev@httpd.apache.org Sent: Sunday, February 10, 2013 11:05 AM Subject: chunked trailers input filter processing by ap_http_filter should be documented So ap_http_filter winds up calling ap_get_mime_headers once

Re: [VOTE] Adopt the comments.a.o system to the 2.2 and 2.4 branch of the httpd docs

2012-07-08 Thread Joe Schaefer
+1! - Original Message - From: Daniel Gruno rum...@cord.dk To: dev@httpd.apache.org; d...@httpd.apache.org Cc: Sent: Sunday, July 8, 2012 6:22 PM Subject: Re: [VOTE] Adopt the comments.a.o system to the 2.2 and 2.4 branch of the httpd docs On 07/08/2012 10:33 PM, Daniel Gruno

Re: Empty cookies [Was Re: libapreq2 co-maintainer]

2012-06-21 Thread Joe Schaefer
apreq does the right thing now by both throwing an exception (indicating a malformed cookie) and parsing the header correctly.  This is a very old subject: Thomas should be using eval like so:    $apreq = APR::Request::Apache2-handle($r);    my $jar = eval { $apreq-jar };    $jar = $@-jar if $@;  

Re: [PATCH] mod_log_forensic security considerations

2012-06-08 Thread Joe Schaefer
- Original Message - From: Daniel Gruno rum...@cord.dk To: dev@httpd.apache.org Cc: Sent: Friday, June 8, 2012 6:24 AM Subject: Re: [PATCH] mod_log_forensic security considerations On 06/08/2012 12:13 PM, Graham Leggett wrote: On 08 Jun 2012, at 12:16 AM, Daniel Ruggeri wrote:

Re: [PATCH] mod_log_forensic security considerations

2012-06-08 Thread Joe Schaefer
: Sent: Friday, June 8, 2012 12:51 PM Subject: Re: [PATCH] mod_log_forensic security considerations On 08 Jun 2012, at 5:45 PM, Joe Schaefer wrote: Well not quite, we'd still have had a problem with storing and archiving those logs even if we hadn't made them available to committers

Re: [PATCH] mod_log_forensic security considerations

2012-06-06 Thread Joe Schaefer
Session cookies sometimes pose a security risk as well. - Original Message - From: Jeff Trawick traw...@gmail.com To: d...@httpd.apache.org; dev@httpd.apache.org Cc: Sent: Wednesday, June 6, 2012 3:46 PM Subject: Re: [PATCH] mod_log_forensic security considerations On Tue, May

Re: svn commit: r1341930 - /httpd/httpd/trunk/docs/manual/suexec.html.en

2012-05-23 Thread Joe Schaefer
This won't happen once the docs are migrated to the CMS ;-) - Original Message - From: Joe Orton jor...@redhat.com To: dev@httpd.apache.org Cc: Sent: Wednesday, May 23, 2012 6:30 PM Subject: Re: svn commit: r1341930 - /httpd/httpd/trunk/docs/manual/suexec.html.en On Thu, May

[RESULTS] Re: [VOTE] CMS site migration

2012-05-11 Thread Joe Schaefer
. From: Joe Schaefer joe_schae...@yahoo.com To: dev@httpd.apache.org dev@httpd.apache.org Cc: d...@httpd.apache.org d...@httpd.apache.org Sent: Tuesday, May 8, 2012 3:14 PM Subject: [VOTE] CMS site migration Please cast your vote accordingly: [ ] : +1 to migrate httpd

Re: svn commit: r817280 - /websites/production/httpd/content/

2012-05-11 Thread Joe Schaefer
Sort of- I forgot httpd has it's own vhost with a mountain of legacy garbage that needed pruning first. - Original Message - From: Jeff Trawick traw...@gmail.com To: dev@httpd.apache.org Cc: Sent: Friday, May 11, 2012 4:43 PM Subject: Re: svn commit: r817280 -

Re: [VOTE] CMS site migration

2012-05-09 Thread Joe Schaefer
Leggett minf...@sharp.fm To: dev@httpd.apache.org Cc: d...@httpd.apache.org d...@httpd.apache.org Sent: Wednesday, May 9, 2012 6:06 AM Subject: Re: [VOTE] CMS site migration On 08 May 2012, at 9:14 PM, Joe Schaefer wrote: Please cast your vote accordingly: [X] : +1 to migrate httpd

Re: [VOTE] CMS site migration

2012-05-09 Thread Joe Schaefer
Damned Y! loves to munge whitespace.  The link is http://s.apache.org/cms-cli - Original Message - From: Joe Schaefer joe_schae...@yahoo.com To: d...@httpd.apache.org d...@httpd.apache.org; dev@httpd.apache.org dev@httpd.apache.org Cc: Sent: Wednesday, May 9, 2012 6:34 AM

Re: [VOTE] CMS site migration

2012-05-09 Thread Joe Schaefer
Death to tables for styling html! - Original Message - From: Daniel Gruno rum...@cord.dk To: dev@httpd.apache.org Cc: Sent: Wednesday, May 9, 2012 8:38 AM Subject: Re: [VOTE] CMS site migration On 08 May 2012, at 9:14 PM, Joe Schaefer wrote: Please cast your vote

[VOTE] CMS site migration

2012-05-08 Thread Joe Schaefer
Please cast your vote accordingly: [ ] : +1 to migrate httpd-site to the CMS [ ] :  0 don't care one way or the other [ ] : -1 leave httpd-site as-is, because... Note: this vote is only for httpd-site, not any of the externals (eg the docs trees) that are pulled in. T-72 hours before the

Re: [VOTE] CMS site migration

2012-05-08 Thread Joe Schaefer
Please cast your vote accordingly: [X] : +1 to migrate httpd-site to the CMS

Re: [DISCUSS] CMS site migration

2012-05-07 Thread Joe Schaefer
See http://www.apache/org/dev/cms and http://www.apache.org/dev/cmsref for details on the CMS. - Original Message - From: Brian J. France br...@brianfrance.com To: dev@httpd.apache.org; Joe Schaefer joe_schae...@yahoo.com Cc: d...@httpd.apache.org d...@httpd.apache.org Sent

[DISCUSS] CMS site migration

2012-05-06 Thread Joe Schaefer
Over on docs@ one of the recent conversations was around moving the site documentation to the CMS, starting first with the httpd site as a testbed. After several hours of hacking on the site that has now been accomplished, so we'd please like everyone to review and comment on the httpd staging

What is apreq?

2012-04-28 Thread Joe Schaefer
Lately lots of different httpd folks are asking me questions about apreq, and from that feedback this post seems to be needed to clarify what apreq's design and goals are all about. Simply put, apreq implements the HTML form specs on the server side.  The name itself was coined by Lincoln Stein

Re: packaging libapreq2 as a dependency

2012-04-27 Thread Joe Schaefer
From: Issac Goldstand mar...@beamartyr.net To: dev@httpd.apache.org Sent: Friday, April 27, 2012 1:55 AM Subject: Re: packaging libapreq2 as a dependency On 27/04/2012 05:12, Joe Schaefer wrote: Now that some time has passed since Philip brought apreq2

packaging libapreq2 as a dependency

2012-04-26 Thread Joe Schaefer
Now that some time has passed since Philip brought apreq2 into trunk it's probably a good time to discuss how best to incorporate it into httpd itself.  Right now the library files are in server/ which basically means we're internally compiling libapreq2 into httpd. Personally I'd prefer to see

Re: [RESULT] Re: [VOTE] Release Apache httpd 2.4.1

2012-02-17 Thread Joe Schaefer
Congrats folks, way to go! - Original Message - From: Jim Jagielski j...@jagunet.com To: dev@httpd.apache.org Cc: Sent: Friday, February 17, 2012 8:42 AM Subject: [RESULT] Re: [VOTE] Release Apache httpd 2.4.1 With the voting ending, I see the following results:   +1

2.3.16 rewrite bug wrt query strings

2012-01-26 Thread Joe Schaefer
I just reverted www.apache.org back to 2.3.15 due to a bug in query-string handling for mod_rewrite in 2.3.16. For some reason query-strings are no longer being appended to typical rewrite rules. HTH

  1   2   3   4   >