Re: [RELEASE CANDIDATE] libapreq-1.34
That's 3 +1s. Uploading to CPAN and announcing... Issac Goldstand wrote: > +1 > > make, test, install with apache-1.41/perl-5.6.2/mp-1.30 > > Issac Goldstand wrote: > > The apreq developers are planning a maintenance release of > > libapreq1. This version primarily addresses an issue noted with > > FireFox 2.0 truncating file uploads in SSL mode. > > > Additionally, the memory allocation algorithm for multipart > > requests has been improved. > > > Please give the tarball at > > > http://www.apache.org/dist/httpd/libapreq/libapreq-1.34.tar.gz > > > a try and report comments/problems/etc. to the apreq-dev list at > > apreq-dev@httpd.apache.org > > > Thanks, Issac >
Re: [RELEASE CANDIDATE] libapreq-1.34
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 make, test, install with apache-1.41/perl-5.6.2/mp-1.30 Issac Goldstand wrote: > The apreq developers are planning a maintenance release of > libapreq1. This version primarily addresses an issue noted with > FireFox 2.0 truncating file uploads in SSL mode. > > Additionally, the memory allocation algorithm for multipart > requests has been improved. > > Please give the tarball at > > http://www.apache.org/dist/httpd/libapreq/libapreq-1.34.tar.gz > > a try and report comments/problems/etc. to the apreq-dev list at > apreq-dev@httpd.apache.org > > Thanks, Issac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklmeXgACgkQ7bEFiW+VItiqDQCfaLWzLlAsp4PhT8kfHtqfp6p6 rKgAn06AYDSMXdEe1poRp5VDHeasu5p4 =qfzS -END PGP SIGNATURE-
Re: [RELEASE CANDIDATE] libapreq-1.34
Joe Schaefer wrote: +1, tests and installs cleanly on Debian-testing with apache 1.3.41 and mod_perl 1.30 and perl 5.8.x. +1 -- FreeBSD 8-current perl 5.8.8 apache 1.3.41 mod_perl 1.30 /me will update freebsd port shortly. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Consultant - P6M7G8 Inc.http://p6m7g8.net Senior Sys Admin- RideCharge, Inc. http://ridecharge.com Contractor - PositiveEnergyUSA http://positiveenergyusa.com ASF Member - Apache Software Foundation http://apache.org FreeBSD Committer - FreeBSD Foundation http://freebsd.org Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
On Jan 7, 2009, at 5:24 AM, Issac Goldstand wrote: *ping* I don't actually see a vote from Steeve - just an advisory that it seems OK. I did vote +1, and am ready to roll (after having a baby boy + getting the flu twice; it's been a busy month ;)) as soon as I see a 3rd binding vote. Since steevehay does seem positive, I'm going to start tagging and rolling, but won't upload or announce until I formally close the vote Issac I don't know if anyone has mentioned this before, but it is our policy to vote on completed artifacts, not "RC" tags or anything else that would be changed subsequent to the vote. Our goal is to verify that the finished tarball actually installs from source, and the only way to verify that is to have the signed tarball in hand before voting. In other words, you will have to call the vote again *after* rolling the actual releasable artifact. In the future, please do not ask people to vote on candidates -- it is a waste of time when we don't care how many version numbers are used between releases. Roy
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
Issac Goldstand wrote: Yay! That makes just a 1.5 year release cycle ;) Me. Thought i might be slow. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Consultant - P6M7G8 Inc.http://p6m7g8.net Senior Sys Admin- RideCharge, Inc. http://ridecharge.com Contractor - PositiveEnergyUSA http://positiveenergyusa.com ASF Member - Apache Software Foundation http://apache.org FreeBSD Committer - FreeBSD Foundation http://freebsd.org Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
- Original Message > From: Issac Goldstand > To: Joe Schaefer > Cc: Steve Hay ; APREQ List > Sent: Wednesday, January 7, 2009 9:03:02 AM > Subject: Re: [RELEASE CANDIDATE] libapreq 1.34-RC4 > > Yay! That makes just a 1.5 year release cycle ;) > > I hope to release today after work. Who's got CPAN karma and > voulenteers to help me upload? For CPAN I recommend letting me do the upload, because none of us have control of the permissions for the apreq 1.x package names.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
Yay! That makes just a 1.5 year release cycle ;) I hope to release today after work. Who's got CPAN karma and voulenteers to help me upload? Joe Schaefer wrote: - Original Message From: Steve Hay To: Issac Goldstand Cc: APREQ List Sent: Wednesday, January 7, 2009 8:54:48 AM Subject: RE: [RELEASE CANDIDATE] libapreq 1.34-RC4 I didn't vote because AFAIK I don't actually have a vote. I have commit access, but I'm not a PMC member and therefore have no vote. Is that correct? Everybody gets a vote ;-), but the ones that count towards the release requirements come from the httpd PMC. Here's my +1 for release Issac.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
- Original Message > From: Steve Hay > To: Issac Goldstand > Cc: APREQ List > Sent: Wednesday, January 7, 2009 8:54:48 AM > Subject: RE: [RELEASE CANDIDATE] libapreq 1.34-RC4 > > I didn't vote because AFAIK I don't actually have a vote. I have commit > access, but I'm not a PMC member and therefore have no vote. Is that > correct? Everybody gets a vote ;-), but the ones that count towards the release requirements come from the httpd PMC. Here's my +1 for release Issac.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
Steve Hay wrote: I didn't vote because AFAIK I don't actually have a vote. I have commit access, but I'm not a PMC member and therefore have no vote. Is that correct? You're not ? mumble grumble. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Consultant - P6M7G8 Inc.http://p6m7g8.net Director IT - RideCharge, Inc. http://ridecharge.com Contractor - PositiveEnergyUSA http://positiveenergyusa.com ASF Member - Apache Software Foundation http://apache.org FreeBSD Committer - FreeBSD Foundation http://freebsd.org Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
RE: [RELEASE CANDIDATE] libapreq 1.34-RC4
I didn't vote because AFAIK I don't actually have a vote. I have commit access, but I'm not a PMC member and therefore have no vote. Is that correct? -Original Message- From: Issac Goldstand [mailto:mar...@beamartyr.net] Sent: 07 January 2009 13:24 Cc: APREQ List Subject: Re: [RELEASE CANDIDATE] libapreq 1.34-RC4 *ping* I don't actually see a vote from Steeve - just an advisory that it seems OK. I did vote +1, and am ready to roll (after having a baby boy + getting the flu twice; it's been a busy month ;)) as soon as I see a 3rd binding vote. Since steevehay does seem positive, I'm going to start tagging and rolling, but won't upload or announce until I formally close the vote Issac Philip M. Gollucci wrote: > Philip M. Gollucci wrote: >> Issac Goldstand wrote: >>> http://people.apache.org/~issac/libapreq-1.34-RC4.tar.gz >> Unit tests blow up spectacularly on solaris 2.10 but I don't think we >> support that and is related to Request.so failing to load. >> >> It does compile. >> >> I'll get a freebsd test for some sanity in the nearish future here. >> >> I wouldn't worry about the solaris blow ups (1.33 doesn't work either) >> >> > Nothing liked getting pissed off to get things to work. > (I believe the only difference I did was -httpd vs -apxs) > > All tests successful. > Files=4, Tests=25, 3 wallclock secs ( 1.22 cusr + 0.17 csys = 1.39 > CPU) > > Solaris 2.10 > apache 1.3.41 > mod_perl 1.30 > perl 5.8.8 > > so thats a +1 > > Neither of Steve's changes are to apreq itself so they don't block the > release. > > +1: stevenhay, pgollucci > +0: > -0: > -1: > > ISSAC did you vote ? if you do we get the required votes. > > If do the release, make sure you send the e-mails from an @apache.org > e-mail. >
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
*ping* I don't actually see a vote from Steeve - just an advisory that it seems OK. I did vote +1, and am ready to roll (after having a baby boy + getting the flu twice; it's been a busy month ;)) as soon as I see a 3rd binding vote. Since steevehay does seem positive, I'm going to start tagging and rolling, but won't upload or announce until I formally close the vote Issac Philip M. Gollucci wrote: Philip M. Gollucci wrote: Issac Goldstand wrote: http://people.apache.org/~issac/libapreq-1.34-RC4.tar.gz Unit tests blow up spectacularly on solaris 2.10 but I don't think we support that and is related to Request.so failing to load. It does compile. I'll get a freebsd test for some sanity in the nearish future here. I wouldn't worry about the solaris blow ups (1.33 doesn't work either) Nothing liked getting pissed off to get things to work. (I believe the only difference I did was -httpd vs -apxs) All tests successful. Files=4, Tests=25, 3 wallclock secs ( 1.22 cusr + 0.17 csys = 1.39 CPU) Solaris 2.10 apache 1.3.41 mod_perl 1.30 perl 5.8.8 so thats a +1 Neither of Steve's changes are to apreq itself so they don't block the release. +1: stevenhay, pgollucci +0: -0: -1: ISSAC did you vote ? if you do we get the required votes. If do the release, make sure you send the e-mails from an @apache.org e-mail.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
Philip M. Gollucci wrote: Issac Goldstand wrote: http://people.apache.org/~issac/libapreq-1.34-RC4.tar.gz Unit tests blow up spectacularly on solaris 2.10 but I don't think we support that and is related to Request.so failing to load. It does compile. I'll get a freebsd test for some sanity in the nearish future here. I wouldn't worry about the solaris blow ups (1.33 doesn't work either) Nothing liked getting pissed off to get things to work. (I believe the only difference I did was -httpd vs -apxs) All tests successful. Files=4, Tests=25, 3 wallclock secs ( 1.22 cusr + 0.17 csys = 1.39 CPU) Solaris 2.10 apache 1.3.41 mod_perl 1.30 perl 5.8.8 so thats a +1 Neither of Steve's changes are to apreq itself so they don't block the release. +1: stevenhay, pgollucci +0: -0: -1: ISSAC did you vote ? if you do we get the required votes. If do the release, make sure you send the e-mails from an @apache.org e-mail. -- Philip M. Gollucci ([EMAIL PROTECTED]) c: 703.336.9354 Consultant - P6M7G8 Inc. http://p6m7g8.net Senior System Admin - RideCharge, Inc. http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
Issac Goldstand wrote: http://people.apache.org/~issac/libapreq-1.34-RC4.tar.gz Unit tests blow up spectacularly on solaris 2.10 but I don't think we support that and is related to Request.so failing to load. It does compile. I'll get a freebsd test for some sanity in the nearish future here. I wouldn't worry about the solaris blow ups (1.33 doesn't work either) -- Philip M. Gollucci ([EMAIL PROTECTED]) c: 703.336.9354 Consultant - P6M7G8 Inc. http://p6m7g8.net Senior System Admin - RideCharge, Inc. http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
Steve Hay wrote: Issac Goldstand wrote: The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Additionally, the memory allocation algorithm for multipart requests has been improved. Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC4.tar.gz a try and report comments/problems/etc. to the apreq-dev list at apreq-dev@httpd.apache.org not to speak for issac, but looks like we're gonna need -RC5 for 1.x. Issac, I should be able to get a test on FreeBSD today before you roll -RC5. I have lots of faith -RC5 will be the last one. -- Philip M. Gollucci ([EMAIL PROTECTED]) c: 703.336.9354 Consultant - P6M7G8 Inc. http://p6m7g8.net Senior System Admin - RideCharge, Inc. http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
RE: [RELEASE CANDIDATE] libapreq 1.34-RC4
Issac Goldstand wrote: > The apreq developers are planning a maintenance release of > libapreq1. This version primarily addresses an issue noted > with FireFox 2.0 truncating file uploads in SSL mode. > > Additionally, the memory allocation algorithm for multipart > requests has been improved. > > Please give the tarball at > > http://people.apache.org/~issac/libapreq-1.34-RC4.tar.gz > > a try and report comments/problems/etc. to the apreq-dev list > at apreq-dev@httpd.apache.org > Looks good with Apache-1.3.41, Perl-5.10.0, mod_perl-1.31-RC4 [*] and VC6. [*] I had to include r719313 to get mod_perl-1.31-RC4 to run with Perl-5.10.0, and r719315 to get libapreq to build (neither 1.33 nor 1.34-RC4 build without r719315 if Perl is built with ithreads).
[RELEASE CANDIDATE] libapreq 1.34-RC4
The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Additionally, the memory allocation algorithm for multipart requests has been improved. Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC4.tar.gz a try and report comments/problems/etc. to the apreq-dev list at apreq-dev@httpd.apache.org Thanks, Issac
Re: [RELEASE CANDIDATE: libapreq-1.34-RC3]
Philip M. Gollucci wrote: -1 perl Makefile.PL Missing right curly or square bracket at Makefile.PL line 196, at end of line syntax error at Makefile.PL line 196, at EOF Execution of Makefile.PL aborted due to compilation errors. That's really odd. Not sure how we vetted it through so far with such a bug - will look into it on Sunday, I hope. Whats currently on branches/1.x does not do this though. Issac, did you want to roll RC4 ? I'm going to need to anyway, since I've misplaced the box that I started the RC roll with last year, so need to start from scratch. Hopefully this time we'll take slightly less than 11 months to review and release ;-) Issac
RE: [RELEASE CANDIDATE: libapreq-1.34-RC3]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -1 perl Makefile.PL Missing right curly or square bracket at Makefile.PL line 196, at end of line syntax error at Makefile.PL line 196, at EOF Execution of Makefile.PL aborted due to compilation errors. Whats currently on branches/1.x does not do this though. Issac, did you want to roll RC4 ? - -- - Philip M. Gollucci ([EMAIL PROTECTED]) o:703.549.2050x206 Senior System Admin - Riderway, Inc. http://riderway.com / http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.8 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFII61LdbiP+9ubjBwRAguIAJkBAEo8kCqCwBvfexpQgYREj4Ba3ACfdfU9 7mNyFFnnyW6YLzsdX83rv+c= =+5lT -END PGP SIGNATURE-
Re: [RELEASE CANDIDATE] libapreq 1.34-RC3
Issac Goldstand wrote: We're still waiting on a couple of PMC votes to roll. If anyone's got time to make test and vote on this, it'd be great. Issac I remember testing this and giving a +1, and seeing another +1 from Randy Kobes, but I can't seem to track down those emails in the archive. http://marc.info/?l=apache-httpd-dev&m=118245721026747&w=2 There looks like some activity rolling the 2.09 release also, so I thought I would drop a friendly ping here to see if there's anything that needs to be done to roll this one also.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC3
On Mon, 4 Jun 2007, Fred Moyer wrote: Issac Goldstand wrote: Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC3.tar.gz a try and report comments/problems/etc. to the apreq-dev list at [EMAIL PROTECTED] All tests OK on Fedora Core 5, perl 5.8.8, apache 1.3.37, mod_perl 1.30. +1 +1 All tests OK on Win32 (XP) - perl-5.8.8, apache-1.3.34 and mod_perl-1.29. -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq 1.34-RC3
Issac Goldstand wrote: > Please give the tarball at > > http://people.apache.org/~issac/libapreq-1.34-RC3.tar.gz > > a try and report comments/problems/etc. to the apreq-dev list > at [EMAIL PROTECTED] All tests OK on Fedora Core 5, perl 5.8.8, apache 1.3.37, mod_perl 1.30. +1
Re: [RELEASE CANDIDATE] libapreq 1.34-RC3
Issac Goldstand wrote: Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC3.tar.gz a try and report comments/problems/etc. to the apreq-dev list at [EMAIL PROTECTED] All tests OK on WinXP (VC6) with perl-5.8.8, apache-1.3.34 and mod_perl-1.29. --
Re: [RELEASE CANDIDATE] libapreq 1.34-RC3
Issac Goldstand <[EMAIL PROTECTED]> writes: > Please give the tarball at > > http://people.apache.org/~issac/libapreq-1.34-RC3.tar.gz > > a try and report comments/problems/etc. to the apreq-dev list > at [EMAIL PROTECTED] +1, tested on Debian stable i386. -- Joe Schaefer
[RELEASE CANDIDATE] libapreq 1.34-RC3
The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Additionally, the memory allocation algorithm for multipart requests has been improved. Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC3.tar.gz a try and report comments/problems/etc. to the apreq-dev list at [EMAIL PROTECTED] Thanks, Issac
Re: No quadratic allocators (was Re: [RELEASE CANDIDATE] libapreq 1.34-RC2)
After going too long without any tuits, I've gotten around to properly
testing this. Looks ok, although I didn't really do anything
in-depth. - I'm going to commit and roll another RC.
Issac
Joe Schaefer wrote:
> Joe Schaefer <[EMAIL PROTECTED]> writes:
>
>
>> Issac Goldstand <[EMAIL PROTECTED]> writes:
>>
>>
>>> The apreq developers are planning a maintenance release of
>>> libapreq1. This version primarily addresses an issue noted
>>> with FireFox 2.0 truncating file uploads in SSL mode.
>>>
>>> Please give the tarball at
>>>
>>> http://people.apache.org/~issac/libapreq-1.34-RC2.tar.gz
>>>
>>> a try and report comments/problems/etc. to the apreq-dev list
>>> at [EMAIL PROTECTED]
>>>
>> +1, tested on Debian stable i386.
>>
>
> Having looked over some recent literature on memory allocation
> attacks, I'm changing my vote to -1. We need to fix the
> crappy quadratic allocator in multipart_buffer_read_body.
>
> Here's a first stab at it- completely untested (I didn't even
> bother trying to compile it). The strategy here though is to
> allocate (more than) twice the amount last allocated, so the
> total amount allocated will sum (as a geometric series) to
> no more than 2 times the final allocation, which is O(n).
>
> The problem with the current code is that the total amount
> allocated is O(n^2), where n is basically the number of packets
> received. This is entirely unsafe nowadays, so we should not bless
> a new release which contains such code.
>
> Index: c/apache_multipart_buffer.c
> ===
> --- c/apache_multipart_buffer.c (revision 531273)
> +++ c/apache_multipart_buffer.c (working copy)
> @@ -273,17 +273,25 @@
> return len;
> }
>
> -/*
> - XXX: this is horrible memory-usage-wise, but we only expect
> - to do this on small pieces of form data.
> -*/
> char *multipart_buffer_read_body(multipart_buffer *self)
> {
> char buf[FILLUNIT], *out = "";
> +size_t nalloc = 1, cur_len = 0;
>
> -while(multipart_buffer_read(self, buf, sizeof(buf)))
> - out = ap_pstrcat(self->r->pool, out, buf, NULL);
> +while(multipart_buffer_read(self, buf, sizeof(buf))) {
> +size_t len = strlen(buf);
> +if (len + cur_len + 1 > nalloc) {
> +char *tmp;
> +nalloc = 2 * (nalloc + len + 1);
> +tmp = ap_palloc(self->r->pool, nalloc);
> +strcpy(tmp, out);
> +out = tmp;
> +}
>
> +strcpy(out + cur_len, buf);
> +cur_len += len;
> +}
> +
> #ifdef DEBUG
> ap_log_rerror(MPB_ERROR, "multipart_buffer_read_body: '%s'", out);
> #endif
>
>
>
Re: No quadratic allocators (was Re: [RELEASE CANDIDATE] libapreq 1.34-RC2)
Joe Schaefer wrote:
> Joe Schaefer <[EMAIL PROTECTED]> writes:
>
>
>> Issac Goldstand <[EMAIL PROTECTED]> writes:
>>
>>
>>> The apreq developers are planning a maintenance release of
>>> libapreq1. This version primarily addresses an issue noted
>>> with FireFox 2.0 truncating file uploads in SSL mode.
>>>
>>> Please give the tarball at
>>>
>>> http://people.apache.org/~issac/libapreq-1.34-RC2.tar.gz
>>>
>>> a try and report comments/problems/etc. to the apreq-dev list
>>> at [EMAIL PROTECTED]
>>>
>> +1, tested on Debian stable i386.
>>
>
> Having looked over some recent literature on memory allocation
> attacks, I'm changing my vote to -1. We need to fix the
> crappy quadratic allocator in multipart_buffer_read_body.
>
>
Argh. I'll try to compile this in and review later today.
> Here's a first stab at it- completely untested (I didn't even
> bother trying to compile it). The strategy here though is to
> allocate (more than) twice the amount last allocated, so the
> total amount allocated will sum (as a geometric series) to
> no more than 2 times the final allocation, which is O(n).
>
>
Maybe I'm missing something in the math behind this, but the current
code [I'll mention now that I don't have the current source at hand as
of the time of writing this, so maybe I'm missing some context]
shouldn't be allocating n^2, but rather n + n-1 + n-2 + ... + 1, where n
is the number of packets received... And just a reminder that we've got
a high chance of "slack" memory at the end of the buffer with the new
code; I don't think it should matter, but I thought I'd mention it anyway.
> The problem with the current code is that the total amount
> allocated is O(n^2), where n is basically the number of packets
> received. This is entirely unsafe nowadays, so we should not bless
> a new release which contains such code.
>
> Index: c/apache_multipart_buffer.c
> ===
> --- c/apache_multipart_buffer.c (revision 531273)
> +++ c/apache_multipart_buffer.c (working copy)
> @@ -273,17 +273,25 @@
> return len;
> }
>
> -/*
> - XXX: this is horrible memory-usage-wise, but we only expect
> - to do this on small pieces of form data.
> -*/
> char *multipart_buffer_read_body(multipart_buffer *self)
> {
> char buf[FILLUNIT], *out = "";
> +size_t nalloc = 1, cur_len = 0;
>
> -while(multipart_buffer_read(self, buf, sizeof(buf)))
> - out = ap_pstrcat(self->r->pool, out, buf, NULL);
> +while(multipart_buffer_read(self, buf, sizeof(buf))) {
> +size_t len = strlen(buf);
> +if (len + cur_len + 1 > nalloc) {
> +char *tmp;
> +nalloc = 2 * (nalloc + len + 1);
> +tmp = ap_palloc(self->r->pool, nalloc);
> +strcpy(tmp, out);
> +out = tmp;
> +}
>
> +strcpy(out + cur_len, buf);
> +cur_len += len;
> +}
> +
> #ifdef DEBUG
> ap_log_rerror(MPB_ERROR, "multipart_buffer_read_body: '%s'", out);
> #endif
>
>
>
No quadratic allocators (was Re: [RELEASE CANDIDATE] libapreq 1.34-RC2)
Joe Schaefer <[EMAIL PROTECTED]> writes:
> Issac Goldstand <[EMAIL PROTECTED]> writes:
>
>> The apreq developers are planning a maintenance release of
>> libapreq1. This version primarily addresses an issue noted
>> with FireFox 2.0 truncating file uploads in SSL mode.
>>
>> Please give the tarball at
>>
>> http://people.apache.org/~issac/libapreq-1.34-RC2.tar.gz
>>
>> a try and report comments/problems/etc. to the apreq-dev list
>> at [EMAIL PROTECTED]
>
> +1, tested on Debian stable i386.
Having looked over some recent literature on memory allocation
attacks, I'm changing my vote to -1. We need to fix the
crappy quadratic allocator in multipart_buffer_read_body.
Here's a first stab at it- completely untested (I didn't even
bother trying to compile it). The strategy here though is to
allocate (more than) twice the amount last allocated, so the
total amount allocated will sum (as a geometric series) to
no more than 2 times the final allocation, which is O(n).
The problem with the current code is that the total amount
allocated is O(n^2), where n is basically the number of packets
received. This is entirely unsafe nowadays, so we should not bless
a new release which contains such code.
Index: c/apache_multipart_buffer.c
===
--- c/apache_multipart_buffer.c (revision 531273)
+++ c/apache_multipart_buffer.c (working copy)
@@ -273,17 +273,25 @@
return len;
}
-/*
- XXX: this is horrible memory-usage-wise, but we only expect
- to do this on small pieces of form data.
-*/
char *multipart_buffer_read_body(multipart_buffer *self)
{
char buf[FILLUNIT], *out = "";
+size_t nalloc = 1, cur_len = 0;
-while(multipart_buffer_read(self, buf, sizeof(buf)))
- out = ap_pstrcat(self->r->pool, out, buf, NULL);
+while(multipart_buffer_read(self, buf, sizeof(buf))) {
+size_t len = strlen(buf);
+if (len + cur_len + 1 > nalloc) {
+char *tmp;
+nalloc = 2 * (nalloc + len + 1);
+tmp = ap_palloc(self->r->pool, nalloc);
+strcpy(tmp, out);
+out = tmp;
+}
+strcpy(out + cur_len, buf);
+cur_len += len;
+}
+
#ifdef DEBUG
ap_log_rerror(MPB_ERROR, "multipart_buffer_read_body: '%s'", out);
#endif
--
Joe Schaefer
Re: [RELEASE CANDIDATE] libapreq 1.34-RC2
On Mon, 30 Apr 2007, Joe Schaefer wrote: Joe Schaefer <[EMAIL PROTECTED]> writes: Issac Goldstand <[EMAIL PROTECTED]> writes: The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC2.tar.gz a try and report comments/problems/etc. to the apreq-dev list at [EMAIL PROTECTED] +1, tested on Debian stable i386. We need a few votes from pmc members before Issac can release. I'm away for the next several days, but will give it a try on Win32 when I return. -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq 1.34-RC2
Joe Schaefer <[EMAIL PROTECTED]> writes: > Issac Goldstand <[EMAIL PROTECTED]> writes: > >> The apreq developers are planning a maintenance release of >> libapreq1. This version primarily addresses an issue noted >> with FireFox 2.0 truncating file uploads in SSL mode. >> >> Please give the tarball at >> >> http://people.apache.org/~issac/libapreq-1.34-RC2.tar.gz >> >> a try and report comments/problems/etc. to the apreq-dev list >> at [EMAIL PROTECTED] > > +1, tested on Debian stable i386. We need a few votes from pmc members before Issac can release. -- Joe Schaefer
Re: [RELEASE CANDIDATE] libapreq 1.34-RC2
Issac Goldstand <[EMAIL PROTECTED]> writes: > The apreq developers are planning a maintenance release of > libapreq1. This version primarily addresses an issue noted > with FireFox 2.0 truncating file uploads in SSL mode. > > Please give the tarball at > > http://people.apache.org/~issac/libapreq-1.34-RC2.tar.gz > > a try and report comments/problems/etc. to the apreq-dev list > at [EMAIL PROTECTED] +1, tested on Debian stable i386. -- Joe Schaefer
Re: [RELEASE CANDIDATE] libapreq 1.34-RC2
Issac Goldstand wrote: The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC2.tar.gz a try and report comments/problems/etc. to the apreq-dev list at [EMAIL PROTECTED] All still OK on WinXP/VC6 with perl-5.8.8, apache-1.3.34, mod_perl-1.29. --
Re: [RELEASE CANDIDATE] libapreq 1.34-RC1
Issac Goldstand <[EMAIL PROTECTED]> writes: > The apreq developers are planning a maintenance release of > libapreq1. This version primarily addresses an issue noted > with FireFox 2.0 truncating file uploads in SSL mode. > > Please give the tarball at > > http://people.apache.org/~issac/libapreq-1.34-RC1.tar.gz +1, tested on Debian stable i386. -- Joe Schaefer
Re: [RELEASE CANDIDATE] libapreq 1.34-RC1
Issac Goldstand wrote: Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC1.tar.gz a try and report comments/problems/etc. to the apreq-dev list at [EMAIL PROTECTED] All tests OK on WinXP (VC6) with perl-5.8.8, apache-1.3.34 and mod_perl-1.29. --
