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

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 the

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

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 the self-contained test suite in library/t. Getting automated builds that run those tests, at least periodically, will make a

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

One of these tests actually reported a problem with the "whimsical" patch under consideration, Yann. But instead of confronting you about it, Joe O just removed that test from the suite prior to release. This is the very last time I expect to say something critical about 2.17. Let's make it the

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

There's literally over 1M tests in library/t/parsers.c; all of them are trivial to adjust to taste. Going forward, if you want to establish different types of parser behaviors, positively document those behaviors in the test suite, just like your predecessors did. Let's not make what happened

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

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 in HEAD as of now looks

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

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 isn't just

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

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 isn't just for mod_perl, but for anyone who wants to take web application development seriously from the apache module viewpoint. It ticks all the boxes:

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

Get Outlook for iOS 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, 2022 at

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

On Mon, Oct 31, 2022 at 7:44 PM Joe Schaefer wrote: > > The reason this took so long for the community to diagnose isn't because of > ill-intent, but because it constituted > a change of behavior in the parser logic that wasn't surfaced in the Changes > file. Please review r1905018 (with a

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

The reason this took so long for the community to diagnose isn't because of ill-intent, but because it constituted a change of behavior in the parser logic that wasn't surfaced in the Changes file. There is never going to come a time when there is any need for urgent action on apreq- if it was

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

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, nor know what this patch actually does, in order to reject it from a GA release. I expect you to say to yourselves: High Risk, Low

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

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, particularly as they relate to cookie standards. The nastiest code in here is the cookie parser logic that was required back then. If

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

Get Outlook for iOS 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 Schaefer

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

On 10/31/22 5:21 PM, Ruediger Pluem wrote: > > > On 10/30/22 4:28 PM, Joe Schaefer wrote: >> And to be frank- framing my input as me slagging on Yann is grotesque.  You >> ship GA releases as a team, and so when you ship a dud >> like 2.17 you should take your lumps as a team. > > I admit

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

On 10/30/22 4:28 PM, Joe Schaefer wrote: > And to be frank- framing my input as me slagging on Yann is grotesque.  You > ship GA releases as a team, and so when you ship a dud > like 2.17 you should take your lumps as a team. I admit that the libapreq2 codebase doesn't get that much review

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

Apologies for the bombast, Joe. Constructively, I’m just offering development advice as an SME, which you are free to act on or not as the team sees fit. But you’re right that this is a Releng issue, not a development one, that I’m trying to surface in terms of how patch management is

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

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

And to be frank- framing my input as me slagging on Yann is grotesque. You ship GA releases as a team, and so when you ship a dud like 2.17 you should take your lumps as a team. Again, you know how to put processes in place to ensure adequate peer review is happening, just like you know

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 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 shipping of late In libapreq2. None of my opinions have changed on that

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

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 > mfd parser

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

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 mfd parser into an error state instead of leaving well enough alone. But basically libapreq2 users get annoyed when the parser breaks on valid input,

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

Found the problem: it's just a misunderstanding about what is admissible in a successful file upload widget. If someone doesn't add a file to the upload widget, it is still a successful control and should be processed as such on the server. In this case, just like with opera, the filename

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

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 wrote: > >>

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

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, not a first time caller. >> >> Yet what a crappy thread (and comments

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

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 wrote: > F/OSS is not about telling others how to write their

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

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

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

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, not a first time caller. > > Yet what a crappy thread (and comments on [1]). > All top posting, unreplyable. > > > > > Libapreq2 was

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

Hi Joe, here comes the "goofer". On Fri, Oct 28, 2022 at 9:05 PM wrote: > > Long time fan, not a first time caller. Yet what a crappy thread (and comments on [1]). All top posting, unreplyable. > > Libapreq2 was intended to be a safe,fast, standards compliant library- > primarily *safe*

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

...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

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

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 wrote: > Long time fan, not a first time caller. > > > > Libapreq2 was intended to be a safe,fast, standards compliant library- > primarily

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

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 around

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

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 libapreq2

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

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

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

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 issue as the one Steve brought up on the 2.17 release > vote thread, please add something

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

Just take this patch: https://svn.apache.org/viewvc/httpd/apreq/trunk/library/t/util.c?r1=1124517=1903497=1903497 and put a lot more labor into the edge cases and malformed headers that you already know trigger RCE. It's a good start, yay, but needs more than just confirmation that the usual

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

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 wrote: > The Unit Test infra already exists in the apreq tree. Just add tests to > the test files that are

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

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

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

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

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 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

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

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 wrote: > The function under scrutiny here is apreq_header_attribute. The only use > case for that function in a form-data > parsing library is

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

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 unusable

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

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: > The

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

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,

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

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 wrote: > Long time fan, not a first time caller. > > > > Libapreq2 was intended to be a