Re: [RESULT: PASS] [VOTE] Release libapreq2-2.17

On Oct 12, 2022, at 9:47 AM, Yann Ylavic <[email protected]> wrote:
>=20
> On Thu, Sep 29, 2022 at 1:16 PM Steve Hay <[email protected]> =
wrote:
>>=20
>> On Thu, 25 Aug 2022 at 09:58, Joe Orton <[email protected]> wrote:
>>>=20
>>> Thanks for testing. The release is approved:
>>>=20
>>> PMC votes: +1 from ylavic, jfclere, jorton
>>>=20
>>> I will promote the release and announce it.
>>>=20
>>=20
>> Thanks for this release. I didn't get round to uploading it to CPAN
>> yet, but a bug report has come in for it anyway:
>>=20
>> https://rt.cpan.org/Public/Bug/Display.html?id=3D144470
>=20
> Do we have an example of a payload/upload which does not pass apreq's
> multipart parsing in 2.17?

I think the reporter is saying any zero-length file will trigger the =
hang? Have you tried testing multipart uploads with one of the uploads =
being a zero-length file, Yann?

I've looked over the diffs between 2.16 and 2.17. I noticed that several =
loops in consume_header_line() in library/parser_header.c have changed =
from

while (nlen > 0) { ... }

to

do { ... } while (nlen > 0);

(including glen and other variants) and the following lines were =
removed:

    if (nlen =3D=3D 0)
        return APR_EBADARG;

With little familiarity with the code, I naively wonder if either or =
both of those might be the cause since the nlen =3D=3D 0 case may not be =
handled now?

Of course, I would really expect the problem to be in =
library/parser_multipart.c, and there are lots of changes there but =
nothing that caught my eye as someone unfamiliar with the code.

Thanks,
Ed