ur 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@httpd.apache.org
>>>
viors 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
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 7:44 PM Joe Schaefer wrote:
> >
> > The reason this took so long for the community to dia
t 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@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
few releases I'll try to
>> participate in the vetting process.
>>
>>
>>
>>
>>
>> On Wed, Nov 2, 2022 at 10:22 AM Joe Schaefer wrote:
>>
>>>
>>>
>>> Get Outlook for iOS <https://aka.ms/o0ukef>
>>> ---
tlook 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 patch
AM Joe Schaefer wrote:
>
>
> 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
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, 2
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 CHAN
ps://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 th
>
>>
>>
>> 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 abo
022 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 wrote:
> > And to be frank- framing my input as me slagging on Yann is grotesque.
> You ship GA releas
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
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 th
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 att
happening between HTTPD’s trunk and apreq’s.
Get Outlook for iOS<https://aka.ms/o0ukef>
From: Joe Orton
Sent: Monday, October 31, 2022 11:07:02 AM
To: dev@httpd.apache.org
Subject: 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
> shipping
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
collaboratio
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
subje
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 in
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,
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 attribute
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:
>
>>
>
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 on
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 code
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 endeari
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 intende
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* befor
...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 w
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 **sa
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
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 release
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 that
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 const
Just take this patch:
https://svn.apache.org/viewvc/httpd/apreq/trunk/library/t/util.c?r1=1124517&r2=1903497&pathrev=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
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 alre
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 J
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:
> H
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 Scha
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 t
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 fo
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 fun
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,
without
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 safe,f
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 c
45 matches
Mail list logo
