Re: [VOTE] 1.3.42 release candidate
Just a reminder; Intention is to release 1.3.42 on Tuesday. If anyone has strong feelings, make them known :-) Nóirín has kindly translated the announcement into English; http://people.apache.org/~noirin/Announcement1.3.txt 2010/1/27 Colm MacCárthaigh c...@allcosts.net: 2010/1/27 Colm MacCárthaigh c...@allcosts.net: On Wed, Jan 27, 2010 at 10:15 PM, Jeff Trawick traw...@gmail.com wrote: 2010/1/27 Colm MacCárthaigh c...@allcosts.net: I still can't figure out where the repos for dev/dist or dist/ are hosted. None of the docs seem up to date. https://dist.apache.org/repos/dist/release/httpd/ https://dist.apache.org/repos/dist/dev/httpd/ Cool, thanks! I'll update the docs :-) And now up at ... http://httpd.apache.org/dev/dist/ -- Colm -- Colm -- Colm
Re: [VOTE] 1.3.42 release candidate
On Wed, Jan 27, 2010 at 3:40 AM, Sander Temme scte...@apache.org wrote: Why don't we do this: roll the same tag with the docs fixes as you indicate immediately above; sign, hash and put them up on dev/dist. Then call 72 hours. We have a quick look to see if smoke emerges and, if not, we can release early next week. That would also give us the opportunity to align PRC. Thoughts? Sounds good to me, I've rerolled, and uploaded to; http://people.apache.org/~colm/1.3.42/ I still can't figure out where the repos for dev/dist or dist/ are hosted. None of the docs seem up to date. -- Colm
Re: [VOTE] 1.3.42 release candidate
2010/1/27 Colm MacCárthaigh c...@allcosts.net: I still can't figure out where the repos for dev/dist or dist/ are hosted. None of the docs seem up to date. https://dist.apache.org/repos/dist/release/httpd/ https://dist.apache.org/repos/dist/dev/httpd/
Re: [VOTE] 1.3.42 release candidate
2010/1/27 Colm MacCárthaigh c...@allcosts.net: On Wed, Jan 27, 2010 at 10:15 PM, Jeff Trawick traw...@gmail.com wrote: 2010/1/27 Colm MacCárthaigh c...@allcosts.net: I still can't figure out where the repos for dev/dist or dist/ are hosted. None of the docs seem up to date. https://dist.apache.org/repos/dist/release/httpd/ https://dist.apache.org/repos/dist/dev/httpd/ Cool, thanks! I'll update the docs :-) And now up at ... http://httpd.apache.org/dev/dist/ -- Colm -- Colm
Re: [VOTE] 1.3.42 release candidate
On Jan 8, 2010, at 4:29 AM, Colm MacCárthaigh wrote: There is a 1.3.42 release candidate for testing, and voting, at; What happened to this, besides making Slashdot? BTW: No regressions. +1 S. Darwin Legadema.local 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov 3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386 1.3.41: Test Summary Report --- t/apache/contentlength.t (Wstat: 0 Tests: 20 Failed: 6) Failed tests: 6, 10, 14, 16, 18, 20 t/apache/headers.t(Wstat: 0 Tests: 24 Failed: 3) Failed tests: 3, 6, 9 t/apache/pr37166.t(Wstat: 0 Tests: 4 Failed: 1) Failed test: 4 t/modules/include.t (Wstat: 0 Tests: 81 Failed: 2) Failed tests: 29, 44 TODO passed: 20 t/modules/proxy.t (Wstat: 0 Tests: 15 Failed: 2) Failed tests: 12-13 t/modules/rewrite.t (Wstat: 0 Tests: 29 Failed: 1) Failed test: 24 t/security/CVE-2008-2364.t (Wstat: 0 Tests: 3 Failed: 2) Failed tests: 2-3 Files=72, Tests=1902, 42 wallclock secs ( 1.27 usr 0.40 sys + 20.64 cusr 4.70 csys = 27.01 CPU) Result: FAIL Failed 7/72 test programs. 17/1902 subtests failed. [warning] server localhost:8529 shutdown [ error] error running tests (please examine t/logs/error_log) 1.3.42: Test Summary Report --- t/apache/contentlength.t (Wstat: 0 Tests: 20 Failed: 6) Failed tests: 6, 10, 14, 16, 18, 20 t/apache/headers.t(Wstat: 0 Tests: 24 Failed: 3) Failed tests: 3, 6, 9 t/apache/pr37166.t(Wstat: 0 Tests: 4 Failed: 1) Failed test: 4 t/modules/include.t (Wstat: 0 Tests: 81 Failed: 2) Failed tests: 29, 44 TODO passed: 20 t/modules/proxy.t (Wstat: 0 Tests: 15 Failed: 2) Failed tests: 12-13 t/modules/rewrite.t (Wstat: 0 Tests: 29 Failed: 1) Failed test: 24 t/security/CVE-2008-2364.t (Wstat: 0 Tests: 3 Failed: 2) Failed tests: 2-3 Files=72, Tests=1902, 38 wallclock secs ( 1.25 usr 0.38 sys + 20.53 cusr 4.68 csys = 26.84 CPU) Result: FAIL Failed 7/72 test programs. 17/1902 subtests failed. [warning] server localhost:8529 shutdown [ error] error running tests (please examine t/logs/error_log) -- Sander Temme scte...@apache.org PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] 1.3.42 release candidate
On Wed, Jan 27, 2010 at 12:43 AM, Sander Temme scte...@apache.org wrote: On Jan 8, 2010, at 4:29 AM, Colm MacCárthaigh wrote: There is a 1.3.42 release candidate for testing, and voting, at; What happened to this, besides making Slashdot? I transited the atlantic twice. I actually wasted about 2 days and 7 EC2 instances trying to document how many build problems there were on modern linux distros due to the glibc/dash problems ... to try and come up with a coherent here's how to build, run, and test ... but it's a complete mess. There are technically enough binding votes for release now, though there is still the outstanding with the bundled docs tree (which ironically turned out to be due to my using dash for testing!). Unless there are any vetoes in the next 2 days, I'd be inclined to release as-is, with the docs tree rerolled to fix includes. It is *definitely* worth never making another release again imo, patches are far less burden than this show! -- Colm
Re: [VOTE] 1.3.42 release candidate
On Jan 26, 2010, at 5:03 PM, Colm MacCárthaigh wrote: On Wed, Jan 27, 2010 at 12:43 AM, Sander Temme scte...@apache.org wrote: On Jan 8, 2010, at 4:29 AM, Colm MacCárthaigh wrote: There is a 1.3.42 release candidate for testing, and voting, at; What happened to this, besides making Slashdot? I transited the atlantic twice. I actually wasted about 2 days and 7 EC2 instances trying to document how many build problems there were on modern linux distros due to the glibc/dash problems ... to try and come up with a coherent here's how to build, run, and test ... but it's a complete mess. A valiant effort! And an illustration of one of the reasons why we're calling it a day: this code is stale and by now impossible to maintain. We have since grown cleaner, more versatile and more maintainable ways to copy data from one file descriptor to another. We move forward on those, and stop clinging to the past. There are technically enough binding votes for release now, though there is still the outstanding with the bundled docs tree (which ironically turned out to be due to my using dash for testing!). Unless there are any vetoes in the next 2 days, I'd be inclined to release as-is, with the docs tree rerolled to fix includes. It is *definitely* worth never making another release again imo, patches are far less burden than this show! Why don't we do this: roll the same tag with the docs fixes as you indicate immediately above; sign, hash and put them up on dev/dist. Then call 72 hours. We have a quick look to see if smoke emerges and, if not, we can release early next week. That would also give us the opportunity to align PRC. Thoughts? S. -- Sander Temme scte...@apache.org PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] 1.3.42 release candidate
On Jan 8, 2010, at 3:53 PM, Colm MacCárthaigh wrote: On Fri, Jan 8, 2010 at 6:58 PM, Rainer Jung rainer.j...@kippdata.de wrote: File htdocs/manual/misc/FAQ.html was previously 150KB and now is only 5KB. I didn't yet load it from the web server itself, but it seems some generation step was missing. The file installed by make install has the same problem. links -src now returns the gzipped body, as we have mod_deflate enabled these days. Since the test tarball wasn't on the dev site, I'm OK with the reroll w/o renumbering... +1
Re: [VOTE] 1.3.42 release candidate
Colm MacCárthaigh wrote: On Fri, Jan 8, 2010 at 7:50 PM, Brian Havard brian.hav...@gmail.com wrote: Colm MacCárthaigh wrote: There is a 1.3.42 release candidate for testing, and voting, at; http://people.apache.org/~colm/1.3.42/ I just tried building on a fairly stock Ubuntu Karmic system and ran into this compile error: gcc -c -I../os/unix -I../include -DLINUX=22 -DHAVE_SET_DUMPABLE -DUSE_HSREGEX -DNO_DL_NEEDED `../apaci` htpasswd.c htpasswd.c:101: error: conflicting types for ‘getline’ /usr/include/stdio.h:651: note: previous declaration of ‘getline’ was here So getline() is a system provided function here. I used the top level configure with /bin/sh changed to /bin/bash as mentioned elsewhere, no options. On fixing this I found that htdigest.c and logrotate.c have the same problem. The obvious fix would be to namespace protect these getline implementations, Thanks for the report - disinclined to fix anything that isn't a regression from 1.3.41 though. This is a security release, for upgraders only - so presumably people who've managed to work around these problems. Making life easy for new users is a deliberate non-goal :-) 2.2 is much much better for new users. Sure, I've no problem with that.
Re: [VOTE] 1.3.42 release candidate
Hi Colm, On 08.01.2010 21:53, Colm MacCárthaigh wrote: On Fri, Jan 8, 2010 at 6:58 PM, Rainer Jungrainer.j...@kippdata.de wrote: File htdocs/manual/misc/FAQ.html was previously 150KB and now is only 5KB. I didn't yet load it from the web server itself, but it seems some generation step was missing. The file installed by make install has the same problem. links -src now returns the gzipped body, as we have mod_deflate enabled these days. I've fixed up the other nits and rerolled, tarballs with new checksums/signatures in the same place now. I'll fix up the Announce language too, waiting for PRC input on that too. md5, sha1, sigs good, tar.Z and tar.gz same contents. FAQ fine, expand.pl gone, Configuration present, no other changes to previous 1.3.42 tarball. There's one other manual related thing I wasn't thinking enough about before writing my last mail: the 1.3.42 manual contains SSI #include virtual statements, the 1.3.41 version not. I (wildly) guess the script expand.pl is usually used during releasing to fix the manual, so that the pages caqn also be read without running them though the web server. At least the contents of expand.pl look like it recursively goes through a directory and resolves all #include virtual in the files. Regards, Rainer
Re: [VOTE] 1.3.42 release candidate
On Sat, Jan 9, 2010 at 11:48 AM, Rainer Jung rainer.j...@kippdata.de wrote: There's one other manual related thing I wasn't thinking enough about before writing my last mail: the 1.3.42 manual contains SSI #include virtual statements, the 1.3.41 version not. I (wildly) guess the script expand.pl is usually used during releasing to fix the manual, so that the pages caqn also be read without running them though the web server. At least the contents of expand.pl look like it recursively goes through a directory and resolves all #include virtual in the files. I ran expand.pl, I'll look into what the hell it's doing :-) -- Colm
Re: [VOTE] 1.3.42 release candidate
On 09.01.2010 12:58, Colm MacCárthaigh wrote: On Sat, Jan 9, 2010 at 11:48 AM, Rainer Jungrainer.j...@kippdata.de wrote: There's one other manual related thing I wasn't thinking enough about before writing my last mail: the 1.3.42 manual contains SSI #include virtual statements, the 1.3.41 version not. I (wildly) guess the script expand.pl is usually used during releasing to fix the manual, so that the pages caqn also be read without running them though the web server. At least the contents of expand.pl look like it recursively goes through a directory and resolves all #include virtual in the files. I ran expand.pl, I'll look into what the hell it's doing :-) Ah, I see. I just tried to run it on top of the manual contained in the tarball, and on my system (Solaris) the result looks fine. It is identical to the manual contained in the 41 tarball. Had to use the system perl, because the hash bang line #!/usr/local/bin/perl5 doesn't fit my local system. Regards, Rainer
Re: [VOTE] 1.3.42 release candidate
Hi, On Fri, 8 Jan 2010, Colm MacCárthaigh wrote: On Fri, Jan 8, 2010 at 7:50 PM, Brian Havard brian.hav...@gmail.com wrote: Colm MacCárthaigh wrote: There is a 1.3.42 release candidate for testing, and voting, at; http://people.apache.org/~colm/1.3.42/ I just tried building on a fairly stock Ubuntu Karmic system and ran into this compile error: gcc -c -I../os/unix -I../include -DLINUX=22 -DHAVE_SET_DUMPABLE -DUSE_HSREGEX -DNO_DL_NEEDED `../apaci` htpasswd.c htpasswd.c:101: error: conflicting types for ?getline? /usr/include/stdio.h:651: note: previous declaration of ?getline? was here So getline() is a system provided function here. I used the top level configure with /bin/sh changed to /bin/bash as mentioned elsewhere, no options. On fixing this I found that htdigest.c and logrotate.c have the same problem. The obvious fix would be to namespace protect these getline implementations, Thanks for the report - disinclined to fix anything that isn't a regression from 1.3.41 though. This is a security release, for upgraders only - so presumably people who've managed to work around these problems. Making life easy for new users is a deliberate non-goal :-) 2.2 is much much better for new users. Just for information: Only out of curiosity (we use 2.2) I tried to compile 1.3.42 on a current OpenSUSE 11.2 system and found also the above described compile problem (but on OpenSUSE 11.1 compiling is ok). The orign seems to lie in the used newer glibc-library respectively the changed file stdio.h. In the glibc-ChangeLog I found 2009-02-26 Ulrich Drepper drep...@redhat.com * libio/stdio.h: dprintf, fmemopen, getdelim, getline, open_memstream, and vdprintf are in POSIX 2008. The above patch would be better but for clarification I added in the Linux block of src/include/ap_config.h the following lines /* glibc 2.10 and later define getline in stdio.h if __USE_XOPEN2K8 * is defined but that conflicts with getline definitions in * support/htpasswd.c, support/htdigest.c and support/logresolve.c. */ #if (__GLIBC__ == 2 __GLIBC_MINOR__ 9) #undef __USE_XOPEN2K8 #endif and it works also (but I am not a C expert). But I accept the arguments of Colm and deleted the apache_1.3.42 directory but I expect some according bug reports after releasing 1.3.42 :-( Regards, Jens
[VOTE] 1.3.42 release candidate
There is a 1.3.42 release candidate for testing, and voting, at; http://people.apache.org/~colm/1.3.42/ As per the changes, there are two updates; *) SECURITY: CVE-2010-0010 (cve.mitre.org) mod_proxy: Prevent chunk-size integer overflow on platforms where sizeof(int) sizeof(long). Reported by Adam Zabrocki. [Colm MacCárthaigh *) Protect logresolve from mismanaged DNS records that return blank/null hostnames. [Jim Jagielski] Notes; this is intended as the final release of Apache httpd 1.3, which has reached end of life. Security updates may continue to be provided by another means (see the CHANGES file for details). Apache httpd 1.3's ./configure script does not work with some versions of dash. Please change the hash-bang line to execute a bourne-compatible shell, such as /bin/bash on platforms affected. Many thanks in advance for your help and testing. -- Colm
Re: [VOTE] 1.3.42 release candidate
On Jan 8, 2010, at 4:29 AM, Colm MacCárthaigh wrote: There is a 1.3.42 release candidate for testing, and voting, at; http://people.apache.org/~colm/1.3.42/ Not seeing gpg sigs or md5s on the tarballs. Didn't we used to do that back then? S. As per the changes, there are two updates; *) SECURITY: CVE-2010-0010 (cve.mitre.org) mod_proxy: Prevent chunk-size integer overflow on platforms where sizeof(int) sizeof(long). Reported by Adam Zabrocki. [Colm MacCárthaigh *) Protect logresolve from mismanaged DNS records that return blank/null hostnames. [Jim Jagielski] Notes; this is intended as the final release of Apache httpd 1.3, which has reached end of life. Security updates may continue to be provided by another means (see the CHANGES file for details). Apache httpd 1.3's ./configure script does not work with some versions of dash. Please change the hash-bang line to execute a bourne-compatible shell, such as /bin/bash on platforms affected. Many thanks in advance for your help and testing. -- Colm -- Sander Temme scte...@apache.org PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] 1.3.42 release candidate
On Jan 8, 2010, at 9:41 AM, Sander Temme wrote: On Jan 8, 2010, at 4:29 AM, Colm MacCárthaigh wrote: There is a 1.3.42 release candidate for testing, and voting, at; http://people.apache.org/~colm/1.3.42/ Not seeing gpg sigs or md5s on the tarballs. Didn't we used to do that back then? Never mind, two sips of coffee later I found the .asc files. Maybe by the end of my cup I'll see hashes. S. -- Sander Temme scte...@apache.org PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] 1.3.42 release candidate
On Fri, Jan 8, 2010 at 5:44 PM, Sander Temme scte...@apache.org wrote: On Jan 8, 2010, at 9:41 AM, Sander Temme wrote: On Jan 8, 2010, at 4:29 AM, Colm MacCárthaigh wrote: There is a 1.3.42 release candidate for testing, and voting, at; http://people.apache.org/~colm/1.3.42/ Not seeing gpg sigs or md5s on the tarballs. Didn't we used to do that back then? Never mind, two sips of coffee later I found the .asc files. Maybe by the end of my cup I'll see hashes. I've uploaded hashes now too :-) -- Colm
Re: [VOTE] 1.3.42 release candidate
On 08.01.2010 13:29, Colm MacCárthaigh wrote: There is a 1.3.42 release candidate for testing, and voting, at; http://people.apache.org/~colm/1.3.42/ md5, sigs good, tar.Z and tar.gz same contents. I did only diff and build yet, not yet run and test, but already noticed the following things: Observations of yet unclear relevance = FAQ seems incomplete File htdocs/manual/misc/FAQ.html was previously 150KB and now is only 5KB. I didn't yet load it from the web server itself, but it seems some generation step was missing. The file installed by make install has the same problem. New file htdocs/manual/expand.pl It's in the branch, but wasn't shipped with the previous tarball. The file is also installed by make install. File src/Configuration missing -- In the previous tarball it was a copy of Configuration.tmpl. Now it is missing. I guess it's not a show stopper (using Configuration.apaci myself). Update of ABOUT_APACHE --- Only in case any of the above warrants rolling a new tarball, it might be good to update ABOUT_APACHE also w.r.t. the EOL state of 1.3.x. Minor things, because not relevant to tarball = Announcement files -- - Semicolon instead of colon - Once 41 - 42 conversion missing in html file - only in html version: added paragraph about CHANGES_1.3.42 is duplicate --- Announcement1.3.txt.orig2010-01-08 15:20:53.0 +0100 +++ Announcement1.3.txt 2010-01-08 17:25:37.412434000 +0100 @@ -6,7 +6,7 @@ version 1.3 of the Apache HTTP Server, which has reached end of life status. - Future critical security updates may be available as patches, via; + Future critical security updates may be available as patches, via: http://www.apache.org/dist/httpd/patches/ --- Announcement1.3.html.orig2010-01-08 15:20:53.0 +0100 +++ Announcement1.3.html 2010-01-08 19:22:33.432594000 +0100 @@ -23,7 +23,7 @@ version 1.3 of the Apache HTTP Server, which has reached end of life status./p -pFuture critical security updates may be available as patches, via;/p +pFuture critical security updates may be available as patches, via:/p pa href=http://www.apache.org/dist/httpd/patches/;http://www.apache.org/dist/httpd/patches//a/p @@ -41,9 +41,6 @@ mod_proxy: Prevent chunk-size integer overflow on platforms where sizeof(int) lt; sizeof(long). Reported by Adam Zabrocki./li/ul -pPlease see the CHANGES_1.3.42 file in this directory for a full list -of changes for this version./p - pApache 1.3.42 is the final stable release of the Apache 1.3 family. We strongly recommend that users of all earlier versions, including 1.3 family release, upgrade to to the current 2.2 version as soon as possible./p @@ -97,7 +94,7 @@ h3Security vulnerabilities/h3 p - The main security vulnerabilities addressed in 1.3.41 are: + The main security vulnerabilities addressed in 1.3.42 are: /p dl dtCVE-2010-0010 (cve.mitre.org)/dt Old Announcement file on dist directory --- File Announcement1.3 on the official download page is still as of version 1.3.39, should likely be copied from file Annoucement1.3.txt when populating the official DL dir. Regards, Rainer
Re: [VOTE] 1.3.42 release candidate
Colm MacCárthaigh wrote:
There is a 1.3.42 release candidate for testing, and voting, at;
http://people.apache.org/~colm/1.3.42/
I just tried building on a fairly stock Ubuntu Karmic system and ran
into this compile error:
gcc -c -I../os/unix -I../include -DLINUX=22 -DHAVE_SET_DUMPABLE
-DUSE_HSREGEX -DNO_DL_NEEDED `../apaci` htpasswd.c
htpasswd.c:101: error: conflicting types for ‘getline’
/usr/include/stdio.h:651: note: previous declaration of ‘getline’ was here
So getline() is a system provided function here.
I used the top level configure with /bin/sh changed to /bin/bash as
mentioned elsewhere, no options.
On fixing this I found that htdigest.c and logrotate.c have the same
problem.
The obvious fix would be to namespace protect these getline
implementations, IE:
Index: src/support/htdigest.c
===
--- src/support/htdigest.c(revision 897307)
+++ src/support/htdigest.c(working copy)
@@ -71,7 +71,7 @@
while ((line[y++] = line[x++]));
}
-static int getline(char *s, int n, FILE *f)
+static int ap_getline(char *s, int n, FILE *f)
{
register int i = 0;
@@ -158,7 +158,7 @@
{
static char line[MAX_STRING_LEN];
-while (!(getline(line, MAX_STRING_LEN, source))) {
+while (!(ap_getline(line, MAX_STRING_LEN, source))) {
putline(target, line);
}
}
@@ -216,7 +216,7 @@
ap_cpystrn(realm, argv[2], sizeof(realm));
found = 0;
-while (!(getline(line, MAX_STRING_LEN, f))) {
+while (!(ap_getline(line, MAX_STRING_LEN, f))) {
if (found || (line[0] == '#') || (!line[0])) {
putline(tfp, line);
continue;
Index: src/support/logresolve.c
===
--- src/support/logresolve.c(revision 897307)
+++ src/support/logresolve.c(working copy)
@@ -71,7 +71,7 @@
#endif /* !MPE !WIN32*/
static void cgethost(struct in_addr ipnum, char *string, int check);
-static int getline(char *s, int n);
+static int ap_getline(char *s, int n);
static void stats(FILE *output);
@@ -278,7 +278,7 @@
* gets a line from stdin
*/
-static int getline (char *s, int n)
+static int ap_getline (char *s, int n)
{
char *cp;
@@ -326,7 +326,7 @@
for (i = 0; i MAX_ERR + 2; i++)
errors[i] = 0;
-while (getline(line, MAXLINE)) {
+while (ap_getline(line, MAXLINE)) {
if (line[0] == '\0')
continue;
entries++;
Index: src/support/htpasswd.c
===
--- src/support/htpasswd.c(revision 897307)
+++ src/support/htpasswd.c(working copy)
@@ -98,7 +98,7 @@
* Get a line of input from the user, not including any terminating
* newline.
*/
-static int getline(char *s, int n, FILE *f)
+static int ap_getline(char *s, int n, FILE *f)
{
register int i = 0;
@@ -547,7 +547,7 @@
char scratch[MAX_STRING_LEN];
fpw = fopen(pwfilename, r);
-while (! (getline(line, sizeof(line), fpw))) {
+while (! (ap_getline(line, sizeof(line), fpw))) {
char *colon;
if ((line[0] == '#') || (line[0] == '\0')) {
Re: [VOTE] 1.3.42 release candidate
On Fri, Jan 8, 2010 at 7:50 PM, Brian Havard brian.hav...@gmail.com wrote: Colm MacCárthaigh wrote: There is a 1.3.42 release candidate for testing, and voting, at; http://people.apache.org/~colm/1.3.42/ I just tried building on a fairly stock Ubuntu Karmic system and ran into this compile error: gcc -c -I../os/unix -I../include -DLINUX=22 -DHAVE_SET_DUMPABLE -DUSE_HSREGEX -DNO_DL_NEEDED `../apaci` htpasswd.c htpasswd.c:101: error: conflicting types for ‘getline’ /usr/include/stdio.h:651: note: previous declaration of ‘getline’ was here So getline() is a system provided function here. I used the top level configure with /bin/sh changed to /bin/bash as mentioned elsewhere, no options. On fixing this I found that htdigest.c and logrotate.c have the same problem. The obvious fix would be to namespace protect these getline implementations, Thanks for the report - disinclined to fix anything that isn't a regression from 1.3.41 though. This is a security release, for upgraders only - so presumably people who've managed to work around these problems. Making life easy for new users is a deliberate non-goal :-) 2.2 is much much better for new users. -- Colm
Re: [VOTE] 1.3.42 release candidate
On Fri, Jan 8, 2010 at 6:58 PM, Rainer Jung rainer.j...@kippdata.de wrote: File htdocs/manual/misc/FAQ.html was previously 150KB and now is only 5KB. I didn't yet load it from the web server itself, but it seems some generation step was missing. The file installed by make install has the same problem. links -src now returns the gzipped body, as we have mod_deflate enabled these days. I've fixed up the other nits and rerolled, tarballs with new checksums/signatures in the same place now. I'll fix up the Announce language too, waiting for PRC input on that too. -- Colm
Re: [VOTE] 1.3.42 release candidate
818dd957edfb2d4747887029dd786332c1bfa7b0 apache_1.3.42.tar.gz builds, starts and serves content on win32 ... about as far as I've got though since my old configs are long gone. I was going to chime in on the prior thread leading to this release and just never found the time to, so will now. I personally think this branch should just be *retired* ... period. I think that Security updates may continue to be provided by another means should be Security updates will no longer be provided by any means Using the word may leaves the user with hope that he/she can still run this version for another n years when the true goal is to have him/her migrate to 2.2+. No? I also think a 2.0.64 should be done as well and in that case you could continue to use the may continue to be provided statement providing a set date for true retirement is included as others had said. Migrating from 2.0 to 2.2 however is not as big a deal as jumping off 1.3 to the 2.x branches IIRC. JMHO Regards G Colm MacCárthaigh wrote: There is a 1.3.42 release candidate for testing, and voting, at; http://people.apache.org/~colm/1.3.42/ As per the changes, there are two updates; *) SECURITY: CVE-2010-0010 (cve.mitre.org) mod_proxy: Prevent chunk-size integer overflow on platforms where sizeof(int) sizeof(long). Reported by Adam Zabrocki. [Colm MacCárthaigh *) Protect logresolve from mismanaged DNS records that return blank/null hostnames. [Jim Jagielski] Notes; this is intended as the final release of Apache httpd 1.3, which has reached end of life. Security updates may continue to be provided by another means (see the CHANGES file for details). Apache httpd 1.3's ./configure script does not work with some versions of dash. Please change the hash-bang line to execute a bourne-compatible shell, such as /bin/bash on platforms affected. Many thanks in advance for your help and testing.
