Bug report for Apache httpd-1.3 [2010/12/19]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |10744|New|Nor|2002-07-12|suexec might fail to open log file| |10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i| |10760|New|Maj|2002-07-12|empty ftp directory listings from cached ftp direc| |14518|Opn|Reg|2002-11-13|QUERY_STRING parts not incorporated by mod_rewrite| |16013|Opn|Nor|2003-01-13|Fooling mod_autoindex + IndexIgnore | |16631|Inf|Min|2003-01-31|.htaccess errors logged outside the virtual host l| |17318|Inf|Cri|2003-02-23|Abend on deleting a temporary cache file if proxy | |19279|Inf|Min|2003-04-24|Invalid chmod options in solaris build| |21637|Inf|Nor|2003-07-16|Timeout causes a status code of 200 to be logged | |21777|Inf|Min|2003-07-21|mod_mime_magic doesn't handle little gif files| |21975|Opn|Nor|2003-07-29|mod_rewrite RewriteMap from external program gets | |22618|New|Maj|2003-08-21|MultiViews invalidates PATH_TRANSLATED if cgi-wrap| |25057|Inf|Maj|2003-11-27|Empty PUT access control in .htaccess overrides co| |26126|New|Nor|2004-01-14|mod_include hangs with request body | |26152|Ass|Nor|2004-01-15|Apache 1.3.29 and below directory traversal vulner| |26790|New|Maj|2004-02-09|error deleting old cache file | |29257|Opn|Nor|2004-05-27|Problem with apache-1.3.31 and mod_frontpage (dso,| |29498|New|Maj|2004-06-10|non-anonymous ftp broken in mod_proxy | |30207|New|Nor|2004-07-20|Piped logs don't close read end of pipe | |30877|New|Nor|2004-08-26|htpasswd clears passwd file on Sun when /var/tmp i| |30909|New|Cri|2004-08-28|sporadic segfault resulting in broken connections | |31975|New|Nor|2004-10-29|httpd-1.3.33: buffer overflow in htpasswd if calle| |32078|New|Enh|2004-11-05|clean up some compiler warnings | |32539|New|Trv|2004-12-06|[PATCH] configure --enable-shared= brocken on SuSE| |32974|Inf|Maj|2005-01-06|Client IP not set | |33086|New|Nor|2005-01-13|unconsistency betwen 404 displayed path and server| |33495|Inf|Cri|2005-02-10|Apache crashes with WSADuplicateSocket failed for| |33772|New|Nor|2005-02-28|inconsistency in manual and error reporting by sue| |33875|New|Enh|2005-03-07|Apache processes consuming CPU| |34108|New|Nor|2005-03-21|mod_negotiation changes mtime to mtime of Document| |34114|New|Nor|2005-03-21|Apache could interleave log entries when writing t| |34404|Inf|Blk|2005-04-11|RewriteMap prg can not handle fpout | |34571|Inf|Maj|2005-04-22|Apache 1.3.33 stops logging vhost| |34573|Inf|Maj|2005-04-22|.htaccess not working / mod_auth_mysql| |35424|New|Nor|2005-06-20|httpd disconnect in Timeout on CGI| |35439|New|Nor|2005-06-21|Problem with remove /../ in util.c and mod_rewri| |35547|Inf|Maj|2005-06-29|Problems with libapreq 1.2 and Apache::Cookie | |3|New|Nor|2005-06-30|Can't find DBM on Debian Sarge| |36375|Opn|Nor|2005-08-26|Cannot include http_config.h from C++ file| |37166|New|Nor|2005-10-19|Under certain conditions, mod_cgi delivers an empt| |37252|New|Reg|2005-10-26|gen_test_char reject NLS string | |38989|New|Nor|2006-03-15|restart + piped logs stalls httpd for 24 minutes (| |39104|New|Enh|2006-03-25|[FR] fix build with -Wl,--as-needed | |39287|New|Nor|2006-04-12|Incorrect If-Modified-Since validation (due to syn| |39937|New|Nor|2006-06-30|Garbage output if README.html is gzipped or compre| |40224|Ver|Nor|2006-08-10|System time crashes Apache @year 2038 (win32 only?| |41279|New|Nor|2007-01-02|Apache 1.3.37 htpasswd is vulnerable to buffer ove| |42355|New|Maj|2007-05-08|Apache 1.3 permits non-rfc HTTP error code = 600 | |43626|New|Maj|2007-10-15|r-path_info returning invalid value | |44768|New|Blk|2008-04-07|Server suddenly reverted to showing test page only| |44926|New|Nor|2008-05-02|1.3.41 binary downloads are faulty MSIs |
Re: [VOTE] Release 2.3.10 tarballs as Alpha
On 16.12.2010 13:51, Jim Jagielski wrote: The Apache httpd 2.3.10-alpha test tarballs are available at: http://httpd.apache.org/dev/dist/ Please vote on whether to release as 2.3.10-alpha. I expect that this will be the last alpha release, allowing us to push on with Beta and finally(!!) a 2.4.0-GA. Vote will close in 72 hours. +1 (alpha) - Sigs and hashes OK - contents of tarballs identical - contents of tag and tarballs identical except for expected deltas plus obsolete ssl expression parser files (only cosmetic, now fixed in roll script) Build on Solaris 8+10 Sparc, SuSE 10 32 and RHEL 5 64 - with shared and with static modules - with module sets none, few, most, all - against bundled APR, external APR/APU 1.4/1.3 and external trunk APR - using expat 2.0.1, pcre 8.11, openssl 0.9.8q, lua 5.1.4 Passed test framework on all those platforms for all available MPMs (except simple) - with shared and static modules using the all module set - with bundled APR, external APR 1.4 and external trunk APR I has some problems when trying to build trunk APR with --disable-dso, but will write a separate mail about that. Regards, Rainer
Re: Fwd: [us...@httpd] SSLRequire UTF-8 characters
On Sunday 19 December 2010, Dr Stephen Henson wrote: On 29/11/2010 19:34, Dr Stephen Henson wrote: You can get a UTF8String from most string types using ASN1_STRING_to_UTF8(). This should be adequate for most purposes: it doesn't handle the more bizarre TeletexString shift conversions but those are rarely encountered in practice. I should have also included a note of warning about ASN1_STRING_to_UTF8(). You cannot safely assume that the result will be a null terminated string as many ASN1 string types can include embedded nulls: this can have security implications in some cases. You mean someone could make a certificate with a CN of foo.apache.org\0evil.com but the CN variable would then only contain foo.apache.org? I think we can safely assume that any certificate that contains an embedded null after converting to UTF8 is malicious. Can we reject such certificates somehow? Should we close the connection if we see such a thing in ssl_var_lookup_ssl_cert? Or should we try to escape the 0-byte in the variable?
Re: SetVirtualDocumentRoot / per request document root / context root?
On Monday 13 December 2010, William A. Rowe Jr. wrote: On 12/13/2010 4:35 AM, Stefan Fritsch wrote: On Monday 13 December 2010, Ondřej Surý wrote: On Mon, Dec 13, 2010 at 04:15, William A. Rowe Jr. wr...@rowe- clan.net wrote: On 12/12/2010 4:23 PM, Stefan Fritsch wrote: On Wednesday 10 November 2010, Stefan Fritsch wrote: The frequency with which this gets asked seems to make it worthwhile doing something, even if this patch isn't the right thing to do. Maybe the larger solution of having a document_root field in the request_rec would be better. Has anyone had a chance to look at Ondrej's patch, already? I didn't get around to doing it, yet. https://issues.apache.org/bugzilla/show_bug.cgi?id=49705 I have looked at the patch and it looks reasonable. The fact that two known modules (mod_vhost_ldap and mod_ftp) copy the whole server_rec just to change the document root means that this feature is needed. Well, at least for mod_ftp it is... I am wondering if the people who want this for mod_vhost_* actually want something else, namely an easy way to get the root dir of a web application in php/cgi/whatever... What about this idea: Add two new cgi env variables: CONTEXT_ROOT and CONTEXT_ROOT_PATH (or APP_ROOT/APP_ROOT_PATH or ...). And add a new config directive Feh... DOCUMENT_ROOT was bad enough, do we have to persist the concept of sharing such things with the app? For that matter, what are the vars that are used in app doc models today, why would we have to invent this again? These things are handled nicely in the JEE world by AJP and the servlet container. They don't seem to work all that well in the CGI-/PHP-world. So before inventing semantics, pointers to the Servlet semantics and/or the ASP.NET semantics would be appropriate, and discuss an established model and naming conventions you've already identified as working nicely. No? JEE has the notion of a servlet context which has a context root path. Servlets only need to know paths relative to the context root and can use the methods getRealPath() to convert it into a file system path and getResource() to convert it into an URI. [1] This does of course not map directly to CGI scripts. But my idea was that the script only knows the path relative to the context root and then prepends the variables CONTEXT_ROOT or CONTEXT_ROOT_PATH to get a URI or file system path, respectively. Maybe CONTEXT_ROOT should be named CONTEXT_ROOT_URI instead. I really think having two such variables always defined to the correct values (even with mod_alias/mod_userdir/ssl-offload/...) would be a good thing, even if it takes a few years until they get adopted by web applications. I don't know how .NET handles this, exactly. But from a bit of googling it seems that the context root may be equivalent to the metabase path. [1] http://download.oracle.com/javaee/6/api/javax/servlet/ServletContext.html
Re: Fwd: [us...@httpd] SSLRequire UTF-8 characters
On 19.12.2010 01:58, Stefan Fritsch wrote: emailaddress=test-...@httpd.apache.org,CN=ca,OU=httpd-test,O=ASF,L=San Francisco,ST=California,C=US Is this what we want? We could use XN_FLAG_DN_REV to keep the old order. I haven't tried UTF8 characters, yet. Thanks, Stefan, for working on this. My idea with using XN_FLAG_RFC2253 was that this is the only kind of standardized X.509 DN string rendering - so I would not add XN_FLAG_DN_REV to the mix, as RFC 2253 (section 2.1) defines the order shown above. Instead of an SSLOption (which would require a request_rec to lookup), I have implemented a per-vhost option for restoring compatibility. Could we pass the request_rec from ssl_var_lookup() to ssl_var_lookup_ssl(), and from there on to ssl_var_lookup_ssl_cert() etc.? SSLOptions seems like the best place to me for such an option, it's where I would expect it to find as an httpd user. I would name the option LegacyDNStringFormat (instead of ...VarFormat). Can we reject such certificates somehow? Should we close the connection if we see such a thing in ssl_var_lookup_ssl_cert? Or should we try to escape the 0-byte in the variable? The latter. I suggest using ASN1_STRING_print_ex() with ASN1_STRFLGS_RFC2253 ~ASN1_STRFLGS_ESC_MSB (will escape them as \0). Kaspar
