Re: [PACTH] sdbm.c, silent warning messages on gcc 2.95.3 with debug
Jeff Trawick wrote: ranier wrote: --- sdbm-old.c2003-07-08 19:55:04.0 -0300 +++ sdbm.c2003-07-08 19:57:52.0 -0300 @@ -495,7 +495,7 @@ while (dbit db-maxbno getdbit(db, dbit)) dbit = 2 * dbit + ((hash (1 hbit++)) ? 2 : 1); -debug((dbit: %d..., dbit)); +debug((dbit: %lu..., dbit)); shouldn't your changes use %ld instead of %lu? It looks to me that dbit and pagb are longs, not unsigned longs. Surely at least dbit should be unsigned? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: filtering huge request bodies (like 650MB files)
Aaron Bannert wrote: On Thu, Dec 11, 2003 at 01:50:46PM -0600, William A. Rowe, Jr. wrote: But the 2.0 architecture is entirely different. We need a poll but it's not entirely obvious where to put one... One suggestion raised in a poll bucket: when a connection level filter cannot read anything more, it passed back a bucket containing a poll descriptor as metadata. Each filter passes this metadata bucket back up. Some filters like mod_ssl would move it from the connection brigade to the data brigade. At one level we'll have to fit whatever I/O multiplexer we come up with in the filters. I'm going to stay out of that discussion. At a lower level, ignoring filters for a moment, we still need a way for applications to be able to multiplex I/O between different I/O types: pipes, files, sockets, IPC, etc... I think this is the root of the problem (and something we should probably move over to the [EMAIL PROTECTED] list, and also something we might want to take up after APR 1.0 is released). This was exactly the conversation we were having at the hackathon. As always, Windows was the problem, but I thought Bill had it licked? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Digest auth - no nonce/replay checking
Dirk-Willem van Gulik wrote: Unless I missed something we nicely issue a nonce during digest auth (based on r-request_time) - but when the reply comes in with an (Proxy-)Authenticate header we use the nonce provided by the client; and do not check if it was any where near reasonably likely that we issued it. So I guess - The release notes and the digest docs should propably contain a warning that we are not hardnened against certain replay attacks. - Long term we propably want to solve this; e.g. by using a hash over a static secret or somethign. I distinctly remember discussing this at the time - guess I didn't have the energy to fix it then :-) Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [patch] digest replay protection
Dirk-Willem van Gulik wrote: Right now we do not verify the nonce using in digest. This means that an attacker can replay the response from another site or section on the web site if - the users username+password is the same across the site. - the realm name is the same Unfortunately that is often the case (and for the real, there is a lot of DAV and webdav out there). Below somewhat addresses that by veryfing that the nonce is actually our own. This doesn't appear to check that the timestamp is anywhere near now, which would prevent same-site replays... Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [patch] digest replay protection
Dirk-Willem van Gulik wrote: This doesn't appear to check that the timestamp is anywhere near now, which would prevent same-site replays... Correct - the trouble with timestap checks is that ?most/some? browsers will NOT cache the password the user has entered; but the 'response' (i.e. nonce+realm+password). So if one sets a 5 minute time out on the time stamp - then users will be prompted for a password every 5 minutes or so. That's crap. So, we should do it right and get the browsers fixed. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [patch] - digest nonce including MM bump, doc and changes.
Dirk-Willem van Gulik wrote: On Thu, 18 Dec 2003, Greg Marr wrote: Couldn't the new member be placed at the end of the request rec so that it's only a minor bump? Sure - does that work across all compilers ? Yes. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Forensic Logging
One of the problems that crops up depressingly often is that someone
gets owned, and they can't find out why. This is generally because the
offending request didn't get logged, because the server died before it
logged it.
So, I've written a forensic logging module. What this does is log the
request as soon as all the headers have been read, then log again when
its complete. Any request that doesn't complete should be viewed with
great suspicion!
I also include a script that parses the log and reports on incomplete
requests.
I propose that we should include this as a standard module. I think we
should also enable it by default. The 1.3 module and script are enclosed
for review. I'm about to embark on porting it to 2.x.
As always, comments/questions welcome.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution,
*if any, must include the following acknowledgment:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgment may appear in the software itself,
*if and wherever such third-party acknowledgments normally appear.
*
* 4. The names Apache and Apache Software Foundation must
*not be used to endorse or promote products derived from this
*software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache,
*nor may Apache appear in their name, without prior written
*permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* Portions of this software are based upon public domain software
* originally written at the National Center for Supercomputing Applications,
* University of Illinois, Urbana-Champaign.
*/
/*
* See also support/check_forensic.
* Relate the forensic log to the transfer log by including
* %{forensic-id}n in the custom log format, for example:
* CustomLog logs/custom %h %l %u %t \%r\ %s %b %{forensic-id}n
* Ben Laurie 29/12/2003
*/
#include httpd.h
#include http_config.h
#include http_log.h
#include assert.h
module MODULE_VAR_EXPORT log_forensic_module;
typedef struct fcfg {
char *logname;
int fd;
} fcfg;
static int next_id;
static void *make_forensic_log_scfg(pool *p, server_rec *s)
{
fcfg *cfg = ap_pcalloc(p, sizeof *cfg);
cfg-logname = logs/forensic_log;
cfg-fd = -1;
return cfg;
}
static void *merge_forensic_log_scfg(pool *p, void *parent, void *new)
{
fcfg *cfg = ap_pcalloc(p, sizeof *cfg);
fcfg *pc = parent;
fcfg *nc = new;
cfg-logname = ap_pstrdup(p, nc-logname ? nc-logname : pc-logname);
cfg-fd = -1;
return cfg;
}
static void open_log(server_rec *s, pool *p)
{
fcfg *cfg = ap_get_module_config(s-module_config, log_forensic_module);
if (cfg-fd = 0)
return;
if (*cfg-logname == '|') {
piped_log *pl;
pl = ap_open_piped_log(p, cfg-logname+1);
if (pl == NULL
Re: Forensic Logging
Jeff Trawick wrote:
Ben Laurie wrote:
One of the problems that crops up depressingly often is that someone
gets owned, and they can't find out why. This is generally because the
offending request didn't get logged, because the server died before it
logged it.
far more often than getting owned are the run-of-the-mill crashes, where
this would save a bit of time too
Sure thing.
I propose that we should include this as a standard module.
+1 (concept)
Excellent, do I hear more?
I think we should also enable it by default.
then simply building new Apache with previous configure invocation will
result in this fresh piece of code inside the server writing logs...
this doesn't sound very safe to me ;)
OK, I live in hope :-)
I think you should have to specify a log file name for it to do anything
Agreed.
and:
2.1: fine with me if module is built/loaded by default
1.3, 2.0: I suggest enabling with --enable-modules={most|all} but not by
default
If it does nothing unless a file is specified, why not enable by default?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
Re: Forensic Logging
Jeff Trawick wrote: Ben Laurie wrote: If it does nothing unless a file is specified, why not enable by default? to avoid silent growth in the set of code built into somebody's server... when does somebody have to add --disable-foo to create a build compatible with what they had with the 1.3.(n-1) release? (I don't feel very strongly about it; it just seems like the right approach to me; over and out) I guess if its disabled by default it doesn't hurt much to have it also not compiled by default. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Forensic Logging
Colm MacCarthaigh wrote: On Mon, Dec 29, 2003 at 01:39:28PM +, Ben Laurie wrote: So, I've written a forensic logging module. What this does is log the request as soon as all the headers have been read, then log again when its complete. Any request that doesn't complete should be viewed with great suspicion! Cool, extremely useful in a lot of circumstances. Just one or two questions though. Is next_id deliberately random? It doesn't seem to get initialised anywhere, though that may be a feature. Static variables are initialised to zero. Could the forensic_id be tied in with mod_unique_id? It seems confusing to have two different methods to generate unique id's for requests. Also with unique_id, I can see it being useful to make CGI's aware of their tracking code via the environment variable. That way a developer can use the same id to track ingress, processing and egress. Well, it would be possible to make it use the unique ID if present. I'm not in favour of requiring it, though, because it appears add a good deal of unnecessary overhead. Or at least, could a host-specific part be added to the forensic id? A lot of people collate logs (myself included ;) from clusters or whatever and this would make life much easier there. Hmmm. You should only be looking at requests that didn't complete, and since it includes the whole header, the host is in there anyway. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Forensic Logging
David Reid wrote: Colm MacCarthaigh wrote: On Mon, Dec 29, 2003 at 01:39:28PM +, Ben Laurie wrote: So, I've written a forensic logging module. What this does is log the request as soon as all the headers have been read, then log again when its complete. Any request that doesn't complete should be viewed with great suspicion! Cool, extremely useful in a lot of circumstances. Just one or two questions though. Is next_id deliberately random? It doesn't seem to get initialised anywhere, though that may be a feature. Static variables are initialised to zero. That's not true on all platforms, sadly :( Then those platforms are broken. KR, ed. 2, A8.7 p.219: A static object not explicitly initialized is initialized as if it (or its members) were assigned the constant 0. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
mod_log_forensic for httpd 2.0
For review - or shall I just commit?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution,
*if any, must include the following acknowledgment:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgment may appear in the software itself,
*if and wherever such third-party acknowledgments normally appear.
*
* 4. The names Apache and Apache Software Foundation must
*not be used to endorse or promote products derived from this
*software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache,
*nor may Apache appear in their name, without prior written
*permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* Portions of this software are based upon public domain software
* originally written at the National Center for Supercomputing Applications,
* University of Illinois, Urbana-Champaign.
*/
/*
* See also support/check_forensic.
* Relate the forensic log to the transfer log by including
* %{forensic-id}n in the custom log format, for example:
* CustomLog logs/custom %h %l %u %t \%r\ %s %b %{forensic-id}n
*
* Credit is due to Tina Bird [EMAIL PROTECTED], whose
* idea this module was.
*
* Ben Laurie 29/12/2003
*/
#include httpd.h
#include http_config.h
#include http_log.h
#include assert.h
#include apr_strings.h
#include apr_atomic.h
#include unistd.h
#include http_protocol.h
module AP_MODULE_DECLARE_DATA log_forensic_module;
typedef struct fcfg {
const char *logname;
apr_file_t *fd;
} fcfg;
static int next_id;
static void *make_forensic_log_scfg(apr_pool_t *p, server_rec *s)
{
fcfg *cfg = apr_pcalloc(p, sizeof *cfg);
cfg-logname = NULL;
cfg-fd = NULL;
return cfg;
}
static void *merge_forensic_log_scfg(apr_pool_t *p, void *parent, void *new)
{
fcfg *cfg = apr_pcalloc(p, sizeof *cfg);
fcfg *pc = parent;
fcfg *nc = new;
cfg-logname = apr_pstrdup(p, nc-logname ? nc-logname : pc-logname);
cfg-fd = NULL;
return cfg;
}
static void open_log(server_rec *s, apr_pool_t *p)
{
fcfg *cfg = ap_get_module_config(s-module_config, log_forensic_module);
if (!cfg-logname || cfg-fd)
return;
if (*cfg-logname == '|') {
piped_log *pl;
pl = ap_open_piped_log(p, cfg-logname+1);
if (pl == NULL) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
couldn't spawn forensic log pipe %s, cfg-logname);
exit(1);
}
cfg-fd = ap_piped_log_write_fd(pl);
}
else {
char *fname = ap_server_root_relative(p, cfg-logname);
apr_status_t rv;
if ((rv = apr_file_open(cfg-fd, fname,
APR_WRITE | APR_APPEND | APR_CREATE,
APR_OS_DEFAULT, p) != APR_SUCCESS)
0
Re: Forensic Logging
Bill Stoddard wrote: Bill Stoddard wrote: Ben Laurie wrote: Bill Stoddard wrote: Ben Laurie wrote: If it does nothing unless a file is specified, why not enable by default? Like Jeff, I am more interested in this for debugging process crashes that are not necessarily related to attacks. Might be useful to enable this function by default in a mode where it records information in an in-process buffer that can easily be sniffed out of a core file (tag the buffer with an eye catcher). Hmmm. The information is easily retrieved from the request structure, why not just find that? It can be difficult to find the request that caused the problem in a threaded mpm. Bill More explanation needed... I've seen too many core dumps with unusable backtraces due to stack corruption (nearly always traced to code for which I don't have the source, unfortunately). So, yea this idea is probably a bit out of scope for mod_forensic. Just thinking out loud. There's certainly a variant on it that does what you describe, yeah. Not really the same thing, though. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Forensic Logging
Colm MacCarthaigh wrote: On Tue, Dec 30, 2003 at 11:49:37AM +, Ben Laurie wrote: Could the forensic_id be tied in with mod_unique_id? It seems confusing to have two different methods to generate unique id's for requests. Also with unique_id, I can see it being useful to make CGI's aware of their tracking code via the environment variable. That way a developer can use the same id to track ingress, processing and egress. Well, it would be possible to make it use the unique ID if present. I'm not in favour of requiring it, though, because it appears add a good deal of unnecessary overhead. I realise that having the value of getpid() and time() to hand is useful for forensic purposes, but a getpid():time():next_id++ will result in duplicates accross even small clusters. Ah, I see :-) does mod_unique_id handle that? It's not unusual to be dealing with many millions of requests per day in a single logfile. From a cursory check here; accross 4 boxes, with a total of 17,000 httpd processes, only 3,000 pids are unique. With about 80 requets/sec, that gives me a probability of about 1/30625 of a request going to two different machines but getting the same pid within one second. Unless I'm reading it wrong, the bounds of next_id is more or less a function of MaxRequestsPerChild, in my example - it's set to 20, so I can expect a mess-up once every 612,500 requests, that's a bit of a pain :/ Well, the most obvious answer is to prepend a box id, which could either be done when I generate the logs or when you collate them. But more than that, it still seems confusing to have two different methods of achieving the same task. If mod_unique_id is too much overhead, then it needs to be rewritten. To my mind, both modules need to generate reliable unique id's for request tracking purposes. Now either there's a good way of doing that, or there's not - but having two different methods and defining two different levels of uniqueness doesn't make sense to me. I have mod_unique_id turned on for my servers, and don't notice much overhead. MTA's like exim, postfix and so on have even more complicated means of generating unique message id's, and they achieve excellent throughput. Though if mod_unique_id can be used if present that'll solve any problems I'd have :) I can easily do that in 2.0 - I can call a give me a unique ID hook, and if mod_unique ID is present, it can give me its. I could also do it by making sure mod_unique_id is run first if present and fishing the ID out of the environment, though that's a bit tacky. Or at least, could a host-specific part be added to the forensic id? A lot of people collate logs (myself included ;) from clusters or whatever and this would make life much easier there. Hmmm. You should only be looking at requests that didn't complete, and since it includes the whole header, the host is in there anyway. The headers arnt host-specific in a cluster, since typically each node is configured to answer for the same hostname. mod_unique_id uses apr_gethostname and the ip address of the node to get around this problem :) I had the wrong end of the stick. Actually that reminds me, these days mod_unique_id's algorithim isn't clever enough for some systems which use L4 switching or anycast balancing, I have an experimental patch here somewhere which can help fix that, must submit it. I'd advocate making the unique bit configurable, that must surely fix it in all cases? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Forensic Logging
Sander Striker wrote: On Tue, 2003-12-30 at 19:52, Ben Laurie wrote: I realise that having the value of getpid() and time() to hand is useful for forensic purposes, but a getpid():time():next_id++ will result in duplicates accross even small clusters. Ah, I see :-) does mod_unique_id handle that? /me sees a previous problem in a different form... Hey Ben, wouldn't it be nice to be able to use the apr uuid functions now? Umm. Yes? Of course, that's problematic in 1.3 - roll on 1.4! As you know, the barrier is select(). I'm beginning to think we should just make the API for select, we know what its got to look like, and let Windoze catch up when it can. Or mark it experimental and subject to change. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c ApacheMonitor.h ApacheMonitor.rc wintty.c
[EMAIL PROTECTED] wrote: nd 2004/01/01 05:26:26 Log: update license to 2004. Why? Unless the file changes in 2004, the copyright doesn't. And, in any case, the earliest date applies, so it gets us nowhere. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: cvs commit: httpd-2.0/modules/loggers mod_log_forensic.c
[EMAIL PROTECTED] wrote: nd 2004/01/02 15:35:59 Modified:modules/loggers mod_log_forensic.c Log: prevent module from segfaulting when not configured. Ooops, forgot to bring that forward from 1.3. Thanks. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: cvs commit: httpd-2.0/server gen_test_char.c
Joe Orton wrote: On Sat, Jan 03, 2004 at 04:31:32PM -, [EMAIL PROTECTED] wrote: ben 2004/01/03 08:31:32 Modified:server gen_test_char.c Log: Make forensic logging safe for POST data. The issue with strchr and NUL is a red herring. I don't think this is a safe change: 0 is now flagged with T_ESCAPE_FORENSIC|T_ESCAPE_LOGITEM|T_HTTP_TOKEN_STOP|T_ESCAPE_SHELL_CMD. At least ap_find_token() assumes that 0 is not flagged with T_HTTP_TOKEN_STOP. I shall fix it. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: cvs commit: httpd-2.0/modules/loggers mod_log_forensic.c
[EMAIL PROTECTED] wrote: bnicholes2004/01/03 11:18:53 Modified:modules/loggers mod_log_forensic.c Log: Don't hardcode the location of the test_char.h header. The path should be added to the INCLUDE path. This patch is broken. Don't make me reverse it. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: cvs commit: httpd-2.0/modules/loggers mod_log_forensic.c
Brad Nicholes wrote: Broken??? jorton already fixed up the INCLUDE path. Ooops. Guess I screwed up, it didn't build for me. Try again. Sorry. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [1.3 PATCH] a different take on forensics
Jeff Trawick wrote: See http://www.apache.org/~trawick/exception_hook_13.html There is a small patch to Apache 1.3 required to make the sample modules work. This is analogous to the toys using the Apache 2.1 exception hook which are described at http://www.apache.org/~trawick/exception_hook.html. You should make the logged strings safe, like mod_log_forensic does, and I think the format should be compatible (which means no space after the colon). Nice idea. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [1.3 PATCH] a different take on forensics
Jeff Trawick wrote: Ben Laurie wrote: Jeff Trawick wrote: See http://www.apache.org/~trawick/exception_hook_13.html You should make the logged strings safe, like mod_log_forensic does, and I think the format should be compatible (which means no space after the colon). Thanks for taking a look! I removed the space after the colon, but at present am not too eager about the escaping of the strings. Why not? If for some reason the module would be seriously considered for committing to cvs, that is a different ballgame, of course. Same if for some other reason I get the idea that folks would actually use it. What I'd really like to see happen is have the patch to core committed. If people are truly interested in having the module(s) put in experimental, that is cool too though I'm not sure I think that's such a good idea until/unless it is clear that it will be used by more than a handful of people (bloat). Right - I think they would be great inclusions, though. Anyway +1 (untested) for the core patch. BTW, I changed the storage allocation of the hook record to use pconf and to clear the list via a cleanup registered on pconf (http://www.apache.org/~trawick/13_fatal_exception_patch). Sounds good. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PATCH] raise MAX_SERVER_LIMIT
Colm MacCarthaigh wrote: On Mon, Jan 26, 2004 at 06:28:03PM +, Colm MacCarthaigh wrote: I'd love to find out what's causing your worker failures. Are you using any thread-unsafe modules or libraries? Not to my knowledge, I wasn't planning to do this till later, but I've bumped to 2.1, I'll try out the forensic_id and backtrace modules right now, and see how that goes. *sigh*, forensic_id didn't catch it, backtrace didn't catch it, whatkilledus didn't catch it, all tried individually. The parent just dumps core; the children live on, serve their content and log their request and then drop off one by one. No uncomplete requests, no backtrace or other exception info thrown into any log. corefile is as useful as ever, unbacktracable. suggestions welcome! mod_log_forensic? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PATCH] configurable Location block speed up
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: or Joshua's virtual keyword on Location , which I like better the more I think about it. ooops... s/Joshua/André/ but Joshua has excellent points about virtualness being a property of the handler. Yes, the server-status handler should know that it is virtual, but the handler hook is too late to skip the directory walk. But the mod_status maintainers (i.e. us) know that mod_status is virtual, so maybe it could tell the core earlier somehow. An earlier hook? preferably something at config time since the virtualness doesn't ever change? Isn't this going to be horribly messy? The current system says oi, you - here's a URL, do you handle it? whereas you'd need to have oi, you, here's a pattern that might match a URL you handle, does it?. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PATCH] configurable Location block speed up
[EMAIL PROTECTED] wrote: Ben Laurie wrote: [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: or Joshua's virtual keyword on Location , which I like better the more I think about it. ooops... s/Joshua/André/ but Joshua has excellent points about virtualness being a property of the handler. Yes, the server-status handler should know that it is virtual, but the handler hook is too late to skip the directory walk. But the mod_status maintainers (i.e. us) know that mod_status is virtual, so maybe it could tell the core earlier somehow. An earlier hook? preferably something at config time since the virtualness doesn't ever change? Isn't this going to be horribly messy? The current system says oi, you - here's a URL, do you handle it? whereas you'd need to have oi, you, here's a pattern that might match a URL you handle, does it?. it should be clean. I'm thinking the module somehow communicates to the core that all its URLs are virtual, i.e., they don't map to the filesystem no way no how not ever. Then we still need the Location /server-status SetHandler status_handler# or whatever it is /Location config/processing to take care of the pattern matching of the URLs, just like today. If both of those things line up, then we can skip the directory walk. Just to be clear: is the idea that you determine the handler (without a directory walk), then determine whether to do the directory walk from that? If so, aren't there cases where the handler gets determined during the directory walk, by .htaccess? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Time for 1.3.30??
Jeff Trawick wrote: Jim Jagielski wrote: I'd like to float the idea of releasing 1.3.30 soonish. Not only are there enough changes to warrant a release, but also to coincide with the changeover to AL 2.0. one question: who would support putting the 1.3 versions of mod_backtrace and mod_whatkilledus in experimental? I saw statements from 2 or 3 folks that seemed interested and I'd be happy to address the outstanding comments and suggestions (fix the directive names, escape the request info written by whatkilledus, allow mod_backtrace to be built on FreeBSD since there is a libexecinfo available there with the required function). No integration with the build planned unless somebody else wants to deal with the AP_ENABLE_EXCEPTION_HOOK flag ;) +1. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: apr/apr-util python dependence
Roy T. Fielding wrote: However I completely disagree that Python (or Perl or PHP) is a good choice for use in build systems. As part of the configure process, I would agree with you, but as part of buildconf, I disagree--not everyone needs to run buildconf--only developers, and if you're a developer, it's *really* not asking that much to have Python on your dev box. Sure it is. If I wasn't so busy I would have vetoed the change on the grounds that it causes httpd to no longer be buildable by developers on the Cray MP. And no, I don't care whether anyone else thinks that is an important requirement. Creating entry barriers is what prevents development on new platforms that you haven't even heard of yet. Or even platforms you have heard of: within hours of this change I had complaints from people who couldn't build snapshots in order to try out mod_log_forensic... Cheers, Ben.
Re: ftp site
Ghanta, Bose wrote: Dear Ben and OpenSSL Team members, Could you kindly answer the following question from one of my group members? I very much appreciate it. I was working on what I originally thought was a bug in our FTP client. Your ftp site has a very long banner (due to the crypto warnings and what all), and the bug opened against our FTP client was that it would disconnect partly through the login banner. After using a packet sniffer, I determined that what is happening is that at a certain point, as your FTP server is sending banner lines, it drops the connection. I'm suspecting it's not doing so gracefully, as I'm seeing a TCP/IP RST segment, not a FIN segment. I'm wondering if you can put me in touch with whoever runs your network servers, so we can get to the bottom of this. It doesn't happen from linux or win2000 boxes here, so I'm suspecting it's something about the way our TCP/IP stack is ACK'ing incoming segments from your FTP server. It may be a bug in your TCP/IP stack that's only triggered in a rare case. Please let me know how you'd like to proceed. What does this question have to do with us? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: cvs commit: httpd-2.0/modules/ssl ssl_engine_log.c
[EMAIL PROTECTED] wrote: jorton 2004/03/10 13:54:17 Modified:modules/ssl ssl_engine_log.c Log: * modules/ssl/ssl_engine_log.c (ssl_log_annotate, ssl_log_annotation, ssl_log_ssl_error): const-ify annotation strings and simplify ssl_log_annotation. -static char *ssl_log_annotation(char *error) +static const char *ssl_log_annotation(char *error) Shouldn't error be const, too? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PROPOSAL] Move httpd to the subversion repository
Justin Erenkrantz wrote: --On Sunday, March 14, 2004 11:18 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: as the GNU, ASF, and SF projects all discovered, full backups by third parties are invaluable. What is the equivalent to rsync, and is it as stable? I think you mean cvsup not rsync. We're currently creating incremental dumps on every commit. Those can be digitally signed and rsync'd off-site. This is far more secure and auditable than any CVS-based solution It is? How? Unless the committer signs (which ISTR was rejected as an option when I suggested it, so I'm assuming that doesn't happen), then they must be signed by the server - a successful attacker can therefore sign his modifications, too. Or am I missing something? (I don't use subversion yet, so forgive me if the answer is obvious). - and is in fact, one reason why the ASF [EMAIL PROTECTED] and the board want to get off CVS. It is news to me that the board have expressed this view. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PROPOSAL] Move httpd to the subversion repository
Justin Erenkrantz wrote: --On Monday, March 15, 2004 10:52 AM + Ben Laurie [EMAIL PROTECTED] wrote: It is? How? Unless the committer signs (which ISTR was rejected as an option when I suggested it, so I'm assuming that doesn't happen), then they must be signed by the server - a successful attacker can therefore sign his modifications, too. Or am I missing something? (I don't use subversion yet, so forgive me if the answer is obvious). We're talking about ensuring the integrity of the repository here, not whether malicious people can commit. I know. With the repository and its dumps, everything is date-ordered. The revisions are sequential and the dumps only contain the changes for that particular revision. Once the changes are made, they can be signed by the server and rsync'd via a third-party 'secure' server (*only* adding the new revisions). In the event of an intrusion, we can use those read-only dumps to compare against our 'live' repository. Also, if a malicious set of commits occur, we can also *quickly* remove those as everything is identified by a changeset/revision number across the repository (again, not possible with CVS as it has per-file revnums). I don't see how this defends against a malicious user that has owned the server for long enough for his changes to have been rsynced to the secure server? It is news to me that the board have expressed this view. No, it's not official, but every time we have an intrusion, we have no useful mechanism of auditing the integrity of our CVS repository as people can modify the RCS files directly and that *has* been a concern brought up by the board on several occasions. With Subversion, it is possible to easily verify the integrity of the repository against backups. -- justin I have yet to be convinced of this. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PROPOSAL] Move httpd to the subversion repository
Justin Erenkrantz wrote: --On Tuesday, March 16, 2004 5:27 PM + Ben Laurie [EMAIL PROTECTED] wrote: I don't see how this defends against a malicious user that has owned the server for long enough for his changes to have been rsynced to the secure server? Because it'd be read-only? That is, the changes won't be on the 'secure' server (i.e. they can't modify things *before* the box was compromised). Once it's compromised, sure, the malicious user can do 'bad' things, but, that's true with any system. Digital signatures by a committer don't add any protection here, either. Those compromised committers can do bad commits, too. However, once the malicious commits are identified, they can be easily rolled back and/or removed from the repository... Hang on. I'm not suggesting that I have some kind of magic bullet that will fix this problem, but there are some fundamental problems with what you say here: a) A compromised server _cannot_ fake user signatures b) Server signatures do _not_ help with compromised users c) You appear to be assuming daily snapshots maintained forever in your story - if so, how do you deal with network problems and the like? How can you tell a commit that didn't make it to the secure server because of a network problem from one that the attacker injected? Do you have a suggestion here? I have yet to be convinced of this. I'm just not sure what you're looking for here. CVS offers *nothing* in the way of integrity checking. Subversion at least gets us moving in the right direction. I think you're underestimating the issues we have auditing our CVS repository. *shrug* No, I'm saying that if you want to move in the right direction, applying PKI magic pixie dust isn't the way to do it - you have to define your threat model and construct a plausible defence against it. In the solution you've rather vaguely outlined, after a server compromise I find myself checking a bunch of commits signed by the compromised server and then making some other vague assumptions I'm not sure I understand to convince myself that they were pre-compromise signatures. I don't feel like my security has been improved. Possibly a clearer explanation is all that is required, or maybe a rethink. I can't tell at this stage. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PROPOSAL] Move httpd to the subversion repository
William A. Rowe, Jr. wrote: At 11:27 AM 3/16/2004, Ben Laurie wrote: Justin Erenkrantz wrote: --On Monday, March 15, 2004 10:52 AM + Ben Laurie [EMAIL PROTECTED] wrote: It is? How? Unless the committer signs (which ISTR was rejected as an option when I suggested it, so I'm assuming that doesn't happen), then they must be signed by the server - a successful attacker can therefore sign his modifications, too. Or am I missing something? (I don't use subversion yet, so forgive me if the answer is obvious). We're talking about ensuring the integrity of the repository here, not whether malicious people can commit. I know. Uhm I beg to differ - I care about both issues :) I didn't say I didn't care! I said I knew what we were talking about. I also care about malicious users. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PROPOSAL] Move httpd to the subversion repository
Justin Erenkrantz wrote: --On Tuesday, March 16, 2004 8:19 PM + Ben Laurie [EMAIL PROTECTED] wrote: c) You appear to be assuming daily snapshots maintained forever in your story - if so, how do you deal with network problems and the like? How can you tell a commit that didn't make it to the secure server because of a network problem from one that the attacker injected? I think you're misunderstanding here. After every commit, an incremental backup containing that revision is generated. It'd then be copied over to a 'backup' site. There is no reason to re-dump the repository every day as that'd be just too big. If a commit is 'missed' due to an attack or whatnot, it'd be obvious because that particular revision number will not appear. This is not like CVS where the prior history can be directly modified by tweaking the RCS files. For CVS, there is no concept of incrementality - the RCS files just aren't stable enough. I'd suggest seeing minotaur:/x1/svn/hot-backups for an idea as to what we're doing right now. (We have yet to digitally sign anything though.) I'm guessing I need subversion to check that out, right? (This is a good example of what Dirk is talking about, and I'm not even on an old system - I'd install subversion from ports, except my ports are out-of-date, and I leave for a trip tomorrow, so I don't want to update them and break my machine just before I go). In the solution you've rather vaguely outlined, after a server compromise I find myself checking a bunch of commits signed by the compromised server and then making some other vague assumptions I'm not sure I understand to convince myself that they were pre-compromise signatures. I don't feel like my security has been improved. Possibly a clearer explanation is all that is required, or maybe a rethink. I can't tell at this stage. I think you're missing that the incrementality causes us to believe the pre-compromise signatures (as the backup can be done in such a way not to modify already existing files). Remember, everything is uniquely ordered in Subversion. If you also don't trust a hot backup, you can also burn those dumps to a 'permanent' media like a DVD-R to later verify it. But, once revision 1 is committed, that's revision 1 forever - it's immutable once it's in the repository. If it *has* changed, that's evidence of a compromise. -- justin OK, I think I can believe this can work, but it needs to be carefully documented and implemented so we don't find that when it comes to it we've missed some small detail (for example, you don't want the remote backups to have the same date as the local ones - you want them to have the date they were transferred). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: FW: SEGV in allocator_free
Mathihalli, Madhusudan wrote: Somehow the message just went to Sander ! -Madhu -Original Message- From: Mathihalli, Madhusudan Sent: Friday, March 19, 2004 11:01 AM To: 'Sander Striker' Subject: RE: SEGV in allocator_free -Original Message- From: Sander Striker [mailto:[EMAIL PROTECTED] [SNIP] But shouldn't APR protect itself against NULL pointers in allocator_free ? And then what? abort()? YES ! IMHO applications shouldn't SEGFAULT - expecially functions like allocator_free() ! They should bail-out with a error message. Continuing to do stuff when you are in an unknown state is a security risk - segfaulting is far safer than printing error messages, sadly. Cheers, Ben.
Re: [OT] sco stuff
Bojan Smojver wrote: On Thu, 2004-03-18 at 06:35, Greg Stein wrote: hehe... it's probably because I sympathize. Back in '96, when I went to work for Microsoft, I caught some heat from some random guy in the Python community. When Guido replied with, effectively, oh, shut the hell up. Greg's contributed more to the Python community than you have (I don't even know who you are), so you have no standing to harsh on him. Okay, maybe not that quote, but close enough :-) Jeez! What next? Microsoft secretly funding Apache development? Putting code in it? (Admit it, it was you!) Or worse [cross heart, hope to die] Linux? Actually, Microsoft have secretly funded Apache development. I'm just not very good at keeping that kind of secret. :-)
Re: mod_log_forensic?
Jeff Trawick wrote: 2) Get approval to commit to stable branch (no attempt made IIRC; typical action is to propose a vote in STATUS file of stable branch and await comments or votes) Done! Votes please... -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: mod_log_forensic?
Jeff Trawick wrote: André Malo wrote: * Jeff Trawick [EMAIL PROTECTED] wrote: André Malo wrote: * Jeff Trawick [EMAIL PROTECTED] wrote: somehow I doubt there will be any problems at all getting it approved, but nobody acted as a champion thus far and asked for approval themselves In fact, I've thought it was by intention, because of the APR 1.0 atomic calls ;-) shouldn't be any serious problems to work with APR 0.9... s/apr_atomic_inc32/apr_atomic_inc/ s/apr_uint32_t next_id/apr_atomic_t next_id/ YMMVslightly Yes, slightly ;-) apr_atomic_inc32 and apr_atomic_inc are not compatible, most notable the interface of the latter is not thread safe. IOW apr_atomic_inc() doesn't return a value so the caller knows what it became :( I forgot that got resolved with 1.0. apr_atomic_cas() could theoretically be used. Additionally there's no Win32 section in apr/atomic in 0.9. The Win32 implementation of atomics for 0.9 is apr_atomic.h. - there needs to be done some apr work before porting mod_log_forensic. What do you want to happen? Add a new increment API to 0.9 that returns a value? There would seem to be several solutions, some with APR dependencies and some without. solution 1: do what mod_unique_id does for generation of the id (no mutex, no atomic); that seems to be optimal solution We could make the 2.0.x version require mod_unique_id. solution 2: get a mutex explicitly; a bit of mess in the code (APR_HAS_THREADS), but not so sucky performance-wise compared with the apr atomics since for many users the apr atomics will be using a mutex under the covers anyway solution 3: see if apr_atomic_cas() is implemented well enough to use solution 4: add some suitable API to APR 0.9 and implement on all platforms Surely not returning the value from the inc is broken anyway? And a harmless change even if you don't consider it broken? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PATCH] Candidate 1: Re: 1.3.3x digest/nonce issue
Jim Jagielski wrote:
On Apr 13, 2004, at 11:13 AM, Jim Jagielski wrote:
static const char *set_bs2000_account(cmd_parms *cmd, void *dummy, char
*name)
{
@@ -3395,6 +3446,9 @@
An HTTP authorization type (e.g., \Basic\) },
{ AuthName, set_authname, NULL, OR_AUTHCFG, TAKE1,
The authentication realm (e.g. \Members Only\) },
+{ AuthNonce, set_authnonce, NULL, OR_AUTHCFG, TAKE1,
+ An authentication token which should be different for each logical
realm. \
+ A random value or the servers IP may be a good choise.\n },
Surely this advice is not good - this value (according to my reading) is
the only secret that prevents forgery of nonces. OTOH, its late, and I
may not be thinking clearly about this - in fact, I'm suspecting that
forgery of nonces is not an issue - the issue is using the same nonce in
different realms - but I'll send this anyway just so it gets discussed.
Also, this isn't really a nonce - the constructed value is - this is a
nonce seed, or something along those lines.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
Re: [1.3 PATCH-ette] mod_log_forensic warning
Jeff Trawick wrote:
pid_t is long on Solaris
+1
Index: src/modules/standard/mod_log_forensic.c
===
RCS file: /home/cvs/apache-1.3/src/modules/standard/mod_log_forensic.c,v
retrieving revision 1.7
diff -u -r1.7 mod_log_forensic.c
--- src/modules/standard/mod_log_forensic.c 21 Feb 2004 15:24:36 - 1.7
+++ src/modules/standard/mod_log_forensic.c 7 May 2004 12:07:08 -
@@ -189,7 +189,7 @@
if (!(id = ap_table_get(r-subprocess_env, UNIQUE_ID))) {
/* we make the assumption that we can't go through all the PIDs in
under 1 second */
-id = ap_psprintf(r-pool, %x:%lx:%x, getpid(), time(NULL), next_id++);
+id = ap_psprintf(r-pool, %lx:%lx:%x, (long)getpid(), time(NULL),
next_id++);
}
rcfg.id = id;
ap_set_module_config(r-request_config, log_forensic_module, rcfg);
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
Re: pgp trust for https?
Nick Kew wrote: We have grown accustomed to two separate trust mechanisms on the 'net; server certs signed by some authority, or the PGP web of trust. I would like to be able to use PGP trust over the web. That would mean (something like) installing a certificate on the server, and signing it with my PGP key. My browser, having access to and trust in, my public key, will then trust the server. No need for any dealings with verispam. Is there any technical reason this shouldn't happen? No, in fact its one of the things we spoke about at EuroOSCon when announcing OpenPGP:SDK.
Re: svn commit: r424584 - in /httpd/httpd/branches/2.2.x/modules/ssl: mod_ssl.c ssl_engine_config.c ssl_engine_init.c ssl_engine_pphrase.c ssl_private.h ssl_util.c
William A. Rowe, Jr. wrote: [EMAIL PROTECTED] wrote: Author: ben Date: Sat Jul 22 07:27:43 2006 New Revision: 424584 URL: http://svn.apache.org/viewvc?rev=424584view=rev Log: Add PKCS#7 support. Modified: httpd/httpd/branches/2.2.x/modules/ssl/mod_ssl.c httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_config.c httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_init.c httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_pphrase.c httpd/httpd/branches/2.2.x/modules/ssl/ssl_private.h httpd/httpd/branches/2.2.x/modules/ssl/ssl_util.c Ben - no objection to this patch, and no objection to backporting to 2.2, or 2.0 - but I didn't see this bounced through status so don't know if this code is already on trunk? Would you make sure you add a forward port note so it's not lost to 2.4? Please don't introduce code on branches/* in general - introduce to trunk/ and backport ;-) OK. While we are at it, can I point out how absurd the SSL[XXX]CertificateFile directive continues to grow? Would it make sense to refactor this in trunk for httpd 2.4 asSSLCertificateFile [DER|PKCS7|PEM (default)] file This sounds like a splendid idea. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: svn commit: r424584 - in /httpd/httpd/branches/2.2.x/modules/ssl: mod_ssl.c ssl_engine_config.c ssl_engine_init.c ssl_engine_pphrase.c ssl_private.h ssl_util.c
Joe Orton wrote: On Sat, Jul 22, 2006 at 02:27:44PM -, [EMAIL PROTECTED] wrote: Author: ben Date: Sat Jul 22 07:27:43 2006 New Revision: 424584 URL: http://svn.apache.org/viewvc?rev=424584view=rev Log: Add PKCS#7 support. -1. We've had an RTC policy on the stable branch for many years: please revert and try again on the trunk, then propose a backport. Sure thing. - fix the code style: spaces not tabs, spaces after commas, etc etc OK, I may have slipped up a couple of times, but what is etc etc? - use APR apr_file_* not ANSI C fopen, I need a FILE *. and close files after you use them Ooops. - the server doesn't even start up (without the new stuff configured): [Sun Jul 23 10:25:14 2006] [info] Loading certificate private key of SSL-aware server [Sun Jul 23 10:25:14 2006] [error] Can't open \x80\x94| Hmmm. Can't reproduce this (on the trunk). - fix the compiler warning (and perhaps hence the above): ssl_util.c: In function 'ssl_read_pkcs7': ssl_util.c:271: warning: 'certs' may be used uninitialized in this function This won't fix the above. certs is actually only uninitialized if death is about to occur. joe -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: svn commit: r424584 - in /httpd/httpd/branches/2.2.x/modules/ssl: mod_ssl.c ssl_engine_config.c ssl_engine_init.c ssl_engine_pphrase.c ssl_private.h ssl_util.c
Ruediger Pluem wrote: On 07/23/2006 02:10 PM, Ben Laurie wrote: Joe Orton wrote: - use APR apr_file_* not ANSI C fopen, I need a FILE *. Maybe you could use BIO_new_file / PEM_read_bio_PKCS7 as it is done in similar situations in other places of mod_ssl. Why? - the server doesn't even start up (without the new stuff configured): [Sun Jul 23 10:25:14 2006] [info] Loading certificate private key of SSL-aware server [Sun Jul 23 10:25:14 2006] [error] Can't open \x80\x94| Hmmm. Can't reproduce this (on the trunk). This is pure luck. You should init pkcs7 to NULL in modssl_ctx_init as done for the other elements of this struct. Sure. You are allowed to just commit the fix, you know? - fix the compiler warning (and perhaps hence the above): ssl_util.c: In function 'ssl_read_pkcs7': ssl_util.c:271: warning: 'certs' may be used uninitialized in this function This won't fix the above. certs is actually only uninitialized if death is about to occur. Then please do STACK_OF(X509) *certs = NULL; instead of STACK_OF(X509) *certs; I am aware of how to fix it (and, indeed, have done so), I'm just pointing out that it won't fix the problem. BTW, it would be nice to be able to run -Wall -Werror, as I normally do, but it seems there's code in the repo that doesn't survive that test. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: svn commit: r424584 - in /httpd/httpd/branches/2.2.x/modules/ssl: mod_ssl.c ssl_engine_config.c ssl_engine_init.c ssl_engine_pphrase.c ssl_private.h ssl_util.c
William A. Rowe, Jr. wrote: Ben Laurie wrote: Ruediger Pluem wrote: On 07/23/2006 02:10 PM, Ben Laurie wrote: [Sun Jul 23 10:25:14 2006] [info] Loading certificate private key of SSL-aware server [Sun Jul 23 10:25:14 2006] [error] Can't open \x80\x94| Hmmm. Can't reproduce this (on the trunk). This is pure luck. You should init pkcs7 to NULL in modssl_ctx_init as done for the other elements of this struct. Sure. You are allowed to just commit the fix, you know? Uhm - he probably would have if the code was on trunk/ ;-) It is. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Backport PCKS#7 patch to 2.2?
Will it be OK to do this? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Backport PCKS#7 patch to 2.2?
Plüm wrote: Please add it to the STATUS file of 2.2.x for voting. Done. Regards Rüdiger -Ursprüngliche Nachricht- Von: Ben Laurie Gesendet: Montag, 31. Juli 2006 16:13 An: Apache List Betreff: Backport PCKS#7 patch to 2.2? Will it be OK to do this? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Hackathon during Q1 2005?
Justin Erenkrantz wrote: On Sat, 11 Dec 2004, Dirk-Willem van Gulik wrote: Sounds a lot more feasible than travelling to .us for a hack. But I'm wondering what this actually achieves? Sure, it gets people to focus on Getting Things Done, but a *scheduled* IRC+pastebin-based hackathon could do that without the hassle and cost of travel. IMHO, a 'virtual hackathon' has been proven not to be effective for us. In the past when we've tried those, they've been a dismal failure as so few people show up. The communication latency is also so high (people get distracted, bored, conflicting schedules) that a 'virtual hackathon' is really little better than the mailing lists we use every day. I think forcing people to get in the same physical room free from other distractions a few times a year (certainly no more than once a quarter!) would have good benefits for us as a project. It'd serve as a forcing function for our focus as a group: and that'd be excellent to drive innovation here. As I just said to David, I think the ASF-wide hackathons aren't as effective because many people are too over-committed to be able to focus on one thing while they are there. So if all the projects follow your lead, then instead they'll be too over-committed to attend (since they'll have to go to all these different hackathons for each project). I don't see how you can win this one - overcommitted people are overcommitted - they either want to give you their attention or they don't. If they don't you aren't going to engineer them into doing it. So, I'm opposed to project-specific hackathons - its inefficient and antisocial. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Hackathon during Q1 2005?
William A. Rowe, Jr. wrote: At 06:19 AM 12/11/2004, Dirk-Willem van Gulik wrote: On Fri, 10 Dec 2004, Justin Erenkrantz wrote: During ApacheCon, a number of us had talked about holding more frequent face-to-face meetings (or summits or whatever). Fred is willing to find a place for us at Apple with space and 'net access. Fred's suggested around the week of February 7th, 2005. That would work for me as well. So, how many people would be interested, willing, and able to make it? Alternatively - I/www.asemantics.com is willing to arrange one in Europe - the Netherlands. Perhaps a lot later in the year -OR- at the SAME time(and wee then will link the two locations). Location will be easy to reach from Airport Schiphol by public transport. Need about 1 or 2 months lead time. In the quarters that ApacheCon/US and ApacheCon/Euro come together, this seems redundant. My other question - does it make sense to do both an EU and US in the same quarter? Or if we get 2 cons/year, should we just add 2 hackathons/year, one in each continent? There will be a hackathon at Apachecon/EU. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: SSL + name based virtual hosting
Enrico Weigelt wrote: * William A. Rowe, Jr. [EMAIL PROTECTED] wrote: snip http://www.ietf.org/rfc/rfc2817.txt spells out methods that the server can -insist- that an upgraded connection is used, and the client can instigate an upgraded connection as well even if the server doesn't require it. But under no conditions is https:// valid for an upgraded connection. The connection never left port 80. The scheme http:// describes a connection to (default) port 80 started as clear text, while the https:// scheme describes an explicit SSL connection to (default) port 443. Upgrade is an addendum to the http:// scheme. What fools are sitting there in the IETF ?! Couldn't they just define a new protocol (probably running on its own port) which allows specifying additional headers *before* SSL handshake starts or another SSL version, which allows passing additional info from client-server before certs are exchanged/checked ? Life could be so easy this way - probably too easy ... Well, that were the same folks who invented IPSEC, which is not NAT'able. It seems its the we have enough IP addresses-sickness ... ... its time to completely redesign HTTP ... There's a well-known solution to this issue: STARTTLS. When you've written the RFCs and persuaded everyone to adopt them, let us know. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Working on some load balancing methods
Jim Jagielski wrote: I'm currently working on code that extended the lb method within the 2.1/2.2 proxy from what is basically a weighted request count to also be a weighted traffic count (as measured by bytes transferred) and a weighted load count (as measured by response time). The former is further along and the methods will be selectable at runtime... This is definitely a scratch I'm itching, but before I spend too much (additional) time on it, I'd like some feedback on whether the concept is one we can all get behind. I am also toying with the idea of supporting a CPU load method when the origin servers are Apache via a custom response header... Errr... mod_backhand? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Working on some load balancing methods
Justin Erenkrantz wrote: --On Saturday, January 8, 2005 10:43 PM + Ben Laurie [EMAIL PROTECTED] wrote: Errr... mod_backhand? mod_backhand doesn't support Apache 2.x: http://www.backhand.org/mod_backhand/FAQ.shtml#question0 Port it? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PATCH] get a pointer to the raw cert from mod_ssl
Joe Orton wrote: On Wed, Feb 02, 2005 at 11:09:47AM +, David Reid wrote: Joe Orton wrote: On Wed, Feb 02, 2005 at 10:17:04AM +, David Reid wrote: Basically this allows us to gain access to the actual cert structure. I don't like the idea of exposing the X509 * directly especially not through a char * interface. Exposing the DER representation (e.g. base64-encoded) through ssl_var_lookup would be better. (of course that's essentially what _CERT_PEM is; but exporting it without the unnecessary PEM trimmings is useful too) The issue is a need to get access to the internals of the structure. By exposing the X509 * directly you expose a dependency on the underlying SSL toolkit. What if mod_ssl was built to use the RSA toolkit; will the X509 * have the same fields and layout? That's why it's preferable to just expose the DER: there's nothing you can't do with the DER that you can do with the X509 * anyway. This is a somewhat frivolous point though. If you expose the DER, then the module will have to have some crypto toolkit to understand it. If its a different one from the one mod_ssl is using, then it can always convert to DER and into its own format, using the same kit mod_ssl uses for the first step. So, it seems to me that this is simply making work for modules to no real gain. Certainly it should only be exported in this format if OpenSSL is in use. BTW, I'd advocate using a hook that was typesafe! Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Augmenting the Apache Web Server with Audit capability
Sarat S wrote: Hi, I apologize if this topic is not relevant to this forum. Please direct me to the suitable list. I'm working on a project that aims at augmenting the Apache Web Server with Audit capability compatible with an audit-enabled operating system(Mac OS X,Free BSD etc). What is an audit-enabled operating system? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Puzzling News
William A. Rowe, Jr. wrote: Fascinating reading (see the bottom two tables of these pages: http://www.securityspace.com/s_survey/data/man.200501/srvch.html?server=Apacherevision=Apache%2F1.3.33 http://www.securityspace.com/s_survey/data/man.200501/srvch.html?server=Apacherevision=Apache%2F2.0.52 What is notable is that the number of users adopting 1.3.33 in place of 2.0 far outweighs the number moving from 1.3 to 2.0. One could argue that we aren't pushing 2.x releases out fast enough. I'd argue the opposite, we aren't refining 2.x sufficiently for folks to garner an advantage over using 1.3. It simply isn't more effective for them to use 2.0 (having tried both.) Consider this as we prepare to announce to the world 2.1-beta. Are folks going to be more impressed with 2.1-beta (in spite of it's wrinkles that a beta always introduces) than what they used before? For anyone who wants to argue that this is a PHP-caused anomaly, note also http://www.securityspace.com/s_survey/data/man.200501/apachemods.html And in sunny news, about 9.6% of domains are hosted on Apache/2[...], with another 14.24% of Apache users not revealing their version (1.x vs 2.x). FWIW, I have yet to run 2.x in anger. Not sure why you find this puzzling. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: svn commit: r159797 - in httpd/httpd/branches/simple-conf/docs/conf: extra/httpd-mpm.conf httpd-std.conf.in
Greg Stein wrote: Euh... don't we need one of those for proper operation? Or do they all have defaults, so a .conf isn't really needed? Dude, one of my biggest complaints with the whole httpd.conf we ship is that we have defaults for _everything_. None of it is needed. And I find it a major PITA trying to figure out what people did when they edit a stock httpd.conf. We should ship an empty one. Or, at least, one with _everything_ commented out. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: simple-conf branch
Greg Stein wrote: On Mon, Apr 04, 2005 at 01:03:27PM -0500, William A. Rowe, Jr. wrote: At 09:37 AM 4/4/2005, Brad Nicholes wrote: +1 to Greg's comment, I also think that for a new users, having a bunch of little .conf files will be more confusing. For experienced users, they will split up the .conf file however they see fit anyway. So it doesn't really matter. With all due respect, if we break this into 'logical' groups, I believe it will make it easier for the new user to learn each group of features, one .conf fragment at a time. Most 'cookbooks' are organized this way, and it turns out to be a great method of teaching. Sorry, but I very much disagree. I think back to the old days of access.conf, httpd.conf, and srm.conf. As an administrator, I absolutely detested that layout. I could NEVER figure out which file a given configuration was in. I always had to search, then edit. We've been to the multiple .conf world before. It sucked. We pulled everything back into a single .conf to get the hell outta there. Small examples are fine. The default configuration should remain as a single .conf file. Which should be almost entirely empty. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: mod_ssl and critical extensions
Stephane Bailliez wrote:
Hi,
I'm facing an annoying issue during a PKI deployment and integration
within an organization.
The CA is created with the authority key identifier set as a critical
extension.
OpenSSL (including 0.9.7g) chokes (voluntarily) on critical extensions
and as a default issue an error such as Certificate Verification: Error
(34): unhandled critical extension
The piece of code involved is in
crypto/x509/x509_vfy.c::check_chain_purpose
if (!(ctx-flags X509_V_FLAG_IGNORE_CRITICAL)
(x-ex_flags EXFLAG_CRITICAL))
{
ctx-error = X509_V_ERR_UNHANDLED_CRITICAL_EXTENSION;
ctx-error_depth = i;
ctx-current_cert = x;
ok=cb(0,ctx);
if (!ok) goto end;
}
There is the flag X509_V_FLAG_IGNORE_CRITICAL which can be set when
creating the SSL context, unfortunately, mod_ssl does not support any
options related to context flags in its configuration, thus it of course
fails during authentication with the message above.
Is there any interest in adding SSL context options to mod_ssl, and if
yes, what is the recommended way if it has been thought ?
Its a pretty dumb idea to ignore critical extensions, so I don't think
this sounds like a great idea...
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
Re: Post-2.2 Thoughts
Paul Querna wrote: So, here is my short-list-made-up-this-afternoon of things I would like to look at doing after 2.2 is branched/released as GA. I welcome additions too. 1) Eliminate the HTTP in HTTPD. I would like to be able to compile httpd with --disable-http. Currently the 'http core' is half mangled with the 'core core'. This was one of the original goals for httpd 2 - so I'm pleased to hear its been revived. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: svn commit: r189761 - /httpd/httpd/branches/fips-dev/acinclude.m4
Joe Orton wrote: On Thu, Jun 09, 2005 at 02:57:37PM -, [EMAIL PROTECTED] wrote: Author: ben Date: Thu Jun 9 07:57:36 2005 New Revision: 189761 URL: http://svn.apache.org/viewcvs?rev=189761view=rev Log: Die properly when path is bollocks. Did you mean to commit this to the branch? (given that it's not FIPS-specific) Well, I should probably also commit to the head, its true. But I hope the long-term plan will be to take the whole FIPS branch to head. - test x == y is not portable, s/==/=/ OK. - don't exit, use AC_MSG_ERROR and pass an error message OK. autoconf sucks. - whitespace should be spaces not tabs OK. -- ApacheCon Europe http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: apache developers documentation!!!
Akins, Brian wrote: On 6/21/05 5:29 PM, Nick Kew [EMAIL PROTECTED] wrote: (2) http://www.apachecon.com/ - come to our module developers tutorial and other talks. When will there be another apachecon US? December. -- ApacheCon Europe http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: mod_smtpd design.
Rian Hunter wrote:
Hi,
Currently there are two approaches we are looking at for mod_smtpd. We
can use the existing request_rec structure, and store smtp specific data
in a structure stucture in the r-request conf vector. With this we can
reuse some of the existing core hooks that make sense (handler,
create_request) while also adding some new ones for smtp (envelope,
called after all necessary commands have been sent). The downside is
that a lot of the request_rec members are extraneous for smtp.
The other approach is to use a custom smtp_request_rec structure for an
smtp session. This has the advantage/disadvantage of defining new hooks
only necessary for smtp, but the disadvantage is that currently in httpd
2.x filters that alter content data require a valid request_rec. It
would be possible to pass a bogus request_rec with the filters set to
ap_add_*_filter*() (or ap_run_insert_filter() so we let reuse core's
handle the Set(Out|In)putFilter directive), except that seems a little
hackish to me.
I don't see why it matters if there are redundant members in
request_rec. However, for purity, it might be cool to divide request_rec
up into common elements and protocol-specific stuff in a union.
The downside of this approach, though, is that you could easily call a
module that expected the wrong union to be filled in. So, it might be
better to have all protocols members in request_rec, but ensure that the
irrelevant ones have values that are consistent with their irrelevancy.
Another approach still would require a fairly large change to the core
and many modules, but it strikes me as a better option...
struct http_data {
.
.
.
};
struct smtp_data {
.
.
.
};
struct request_rec {
.
. /* common stuff */
.
struct http_data *http;
struct smtp_data *smtp;
}
with http set to NULL when smtp data is there. This means that modules
that thought they were dealing with HTTP data on an SMTP request would
die rather than behaving unpredictably. Of course, well-behaved modules
would handle this gracefully.
Cheers,
Ben.
--
ApacheCon Europe http://www.apachecon.com/
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
Re: svn commit: r220307 - in /httpd/httpd/trunk/modules: metadata/mod_setenvif.c ssl/mod_ssl.c ssl/mod_ssl.h ssl/ssl_expr_eval.c
David Reid wrote: Joe Orton wrote: On Fri, Aug 05, 2005 at 08:00:01PM +0200, Martin Kraemer wrote: On Tue, Aug 02, 2005 at 07:14:10PM +0200, Martin Kraemer wrote: I wanted something like SSLRequire committers in SSLPeerExtList(1.3.6.1.4.1.18060.1); to mean at least one extension with an OID of 1.3.6.1.4.1.18060.1 with a value of 'committers' exists in the client cert. I'll be on vacation next week, and will send in another patch after that. OK, hope you had a good holiday. I wasn't trying to argue about the semantics just to nitpick the naming. Having SSL in the SSLRequire function is redundant, but not in the context of mod_setenvif. So, my preference is: SSLRequire committers in PeerExtList(1.3.6.1.4.1.18060.1); SetEnvIf SSL_PeerExtList(etc) ... +1 on the revised naming. Patch looks OK as well. Late to the party here, but giving the same function two different names sucks! Or am I misunderstanding? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: cvs commit: httpd-2.0/server Makefile.in
[EMAIL PROTECTED] wrote: jerenkrantz2002/12/11 13:09:16 Modified:server Makefile.in Log: Take a stab at fixing the brokenness in our tree (grr!). ls -1 is bound to be more portable than find -maxdepth, but I suspect it may not be as portable as it really should. man ls says By default, ls lists one entry per line to standard output; the exceptions are to terminals or when the -C option is specified. AFAIK, this completely standard behaviour. You shouldn't need the -1. Also, can I offer, should you be completely paranoid: echo $$dir/*.h | sed 's/ /\ /g' Cheers, Ben. Revision ChangesPath 1.80 +1 -1 httpd-2.0/server/Makefile.in Index: Makefile.in === RCS file: /home/cvs/httpd-2.0/server/Makefile.in,v retrieving revision 1.79 retrieving revision 1.80 diff -u -u -r1.79 -r1.80 --- Makefile.in 3 Dec 2002 09:47:11 - 1.79 +++ Makefile.in 11 Dec 2002 21:09:16 - 1.80 @@ -47,7 +47,7 @@ tmp=export_files_unsorted.txt; \ rm -f $$tmp touch $$tmp; \ for dir in $(EXPORT_DIRS); do \ - find $$dir -maxdepth 1 -type f -name '*.h' $$tmp; \ + ls -1 $$dir/*.h $$tmp; \ done; \ sort -u $$tmp $@; \ rm -f $$tmp -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: FW: Apache socket question
Jeff Trawick wrote: While this is probably a bad idea, I bet that if you could trick ap_lingering_close() not to close your socket when the connection is closed, you might be able to get away with this. The relevent line in server/connection.c:214 is: apr_socket_t *csd = ap_get_module_config(c-conn_config, core_module); So, something like: ap_set_module_config(c-conn_config, core_module, NULL); in your module might do the trick. But, don't expect us to support this. =) -- justin in fact, we might intentionally do something to make that blow up :) my suggestion on apache-modules was to set c-aborted in the pre-connection hook, presumably after passing the descriptor successfully to another process ap_lingering_close() doesn't perform the shutdown() if c-aborted Icky! Presumably the nice thing to do would be to invent a flag that inhibits the shutdown? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: response handlers get all requests
[EMAIL PROTECTED] wrote: Marc M. Adkins wrote: The ap_hook_handler() call does not specify the handler key from the corresponding AddHandler configuration directive. As a consequence, the specified handler function must look at and accept or decline each request. yes, you are right. IMO that sucks, for a number of reasons: * the Apache 1.3 core was better about it and only called handlers when the request type matched a type the handler was interested in, * we had to change the module API to accomodate this regression in the core, and * now we have a distributed performance hit in 2.x, because the core is calling all these modules who don't care about the request which makes the CPU fetch crap instructions into the i-cache. This won't show up as a hot spot in a profiler, because it is spread among all the different handlers and other code which is now taking more frequent i-cache misses. ...but I'll shut up because I don't have a patch or a design for one yet. By contrast, output filters only see requests in which they have interest. Clearly a better situation. The change in handlers was made for a reason. The problem is, I've forgotten the reason! A survey of all the existing handlers might well reveal it - otoh, the reason might simply be that filtering hooks didn't fit neatly with the new hook API. Which is, of course, fixable, at the cost of some complication. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Finding race conditions/deadlock using Stanford Checker
Aaron Bannert wrote: Who are the developers who could answer my is this a race condition questions? Anyone on this list (or on the [EMAIL PROTECTED] list). If you think you've found a race condition, please just post it to the appropriate list so that we can all discuss it. Any help you can provide would be appreciated. Note that if it is a security issue (which race conditions often are), you should post to [EMAIL PROTECTED], not an open list. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: UK postal address for Apache
objectworlds wrote: Does Apache have a postal address in the UK ? No. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PATCH] UDP Listeners (was Re: DNS+HTTP redirection system insidean Apache module)
William A. Rowe, Jr. wrote: All this shows that running UDP in Apache can make sense, and I tried to get some attention about it one year ago.. But somehow everybody thought that UDP inside Apache can be used only for HTTP-over-UDP, which is indeed controversial.. I hope that full UDP-support will not be neglected in the next Apache release :-) Let me offer one thought here. I'm -0 on including this patch in Apache for one very simple reason. We are a standards-based server. Yes, UDP is a clear standard, as is HTTP. But in order to incorporate your patch, I would want to see nothing less than a draft RFC explaining the what and why of what you are accomplishing, with community review. I agree with the rest of what you said, but this doesn't seem right to me, unless I'm misunderstanding. For a start, RFCs are not appropriate for software architecture. Secondly, there's a ton of RFCs describing services based on UDP. I can see no problem with having Apache have generalised support for such services. But perhaps I'm missing the point? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PATCH][1.3] Segfault in mod_proxy
Thom May wrote: Hi folks, so it seems that ProxyPass operation has been broken since at least 1.3.9; we're currently firefighting our way through the list of debian bugs and found http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=57316 - ProxyPass to ftp urls causes apache to segfault. The attached patch borrows from proxy_http.c's logic and was written by Tollef Fog Heen, with hindrance from myself. If no-one has any objections I'll commit the fix shortly. You can't commit EAPI changes to the base. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PATCH] mod_status optional extension hook
Joe Orton wrote: This adds an optional hook so that modules can put their own status information in the server-status page when mod_status is loaded. (mod_ssl has code which can use this to output session cache status). Any objections? * mod_status.h: New file. * mod_status.c: Implement the status hook. (status_handler): Call the status hook. Sounds good to me, though its not obvious how the module adds to the page? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PATCH] Trivial patch for C++ modules (2.0.47)
William A. Rowe, Jr. wrote:
At 10:44 PM 7/31/2003, Mahadevan R wrote:
While trying to write an Apache2 module in C++, I found that in the command table,
AP_INIT_TAKE1 has to be used like this:
AP_INIT_TAKE1( Directive, (cmd_func) drctv_handler, NULL, OR_ALL, help string)
The compiler I'm using (MSVC++ 6.0) does not support designated initializers. Hence
the compiler expects the function drctv_handler to have a signature of
const char *(*cmd_func) (); whereas it actually has a signature of
const char *(*take1) (cmd_parms *parms, void *mconfig, const char *w);.
The situation can be easily solved (worked around?) by changing the definition of
AP_INIT_TAKE1 (and its friends) in http_config.h to:
# define AP_INIT_TAKE1(directive, func, mconfig, where, help) \
{ directive, (cmd_func) func, mconfig, where, TAKE1, help }
We have a very strong policy against casts at all costs when it will likely
mask a developers error. I would be much more happy to consider a patch
that introduced specific prototypes for the TAKE1_fn, TAKE12_fn, etc
function type declarations.
Isn't the point that you can't, because they're unions? So, if you have
designated initialisers, they can be checked, if not, they _have_ to be
cast. From memory.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
Re: [Fwd: Possible security flaw! (Format BUG)]
Ranier Vilela wrote:
Sorry, the mpm_common.c.diff was empty.
--- mpm_common.c 2003-08-31 06:06:25.0 -0300
+++ mpm_common_old.c 2003-08-31 05:57:14.0 -0300
@@ -808,7 +808,7 @@
if (!strcmp(dash_k_arg, restart)) {
if (!running) {
-printf(%s\n, httpd not running, trying to start);
+printf(httpd not running, trying to start\n);
}
else {
*exit_status = send_signal(otherpid, SIGHUP);
@@ -818,7 +818,7 @@
if (!strcmp(dash_k_arg, graceful)) {
if (!running) {
-printf(%s\n, httpd not running, trying to start);
+printf(httpd not running, trying to start\n);
}
else {
*exit_status = send_signal(otherpid, SIGUSR1);
That's backwards. In any case, there is no flaw here, but it would be
more efficient to replace printf with puts (and lose the trailing
newline, of course).
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
Re: cvs commit: httpd-dist KEYS
[EMAIL PROTECTED] wrote: martin 2003/09/08 04:03:40 Modified:.KEYS Log: Add my 768/FDE534D1 key That's a little weak, isn't it? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Hook ordering
Cliff Woolley wrote: Noel and I had a little discussion just now on IRC about hook ordering and the fact that in 2.0 we have made the admin's life a little harder by hard-coding the ordering of certain modules (eg mod_dav vs mod_jk2). Basically the problem is that a completely automatic ordering is good for the cases that have particular ordering constraints, but bad for the cases where the ordering is underconstrained because the admin has no choice as to which of the possible valid orderings is used. So we talked about two things in particular that would help: 1) A means to list all the hooks and which modules had hooked them in which order (e.g., httpd --list-hooks) as a diagnostic. For this one, it looks like we might need a way to keep track at a global scope what hooks there are. Right now, the only list of hooks is static to the file the hooks were declared in (a static struct called _hooks in that file). Or we could just only allow --list-hooks to list certain hooks which are known to the core a priori. I thought I had this in there already? Long time since I've looked, though. 2) A means to restore some control to the admin. Noel suggests expanding the current APR_HOOK_FIRST/MIDDLE/LAST etc scheme with some priority bits which could be set by the admin: We could have [CLASS|priority]. The current ones, APR_HOOK_FIRST etc, are the CLASS. Admins could be given a HookPriority directive by which they could add a priority for a given mod+method. So the class would be the high-order bits and the priority would be the low-order bits, basically. Thus if the admin doesn't use the HookPriority directive, everything works as-is. But if they do, it just provides additional control over list insertion. +1! They're already spaced apart somewhat, aren't they? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Hook ordering
Cliff Woolley wrote: On Fri, 17 Oct 2003, Ben Laurie wrote: For this one, it looks like we might need a way to keep track at a global scope what hooks there are. Right now, the only list of hooks is static to the file the hooks were declared in (a static struct called _hooks in that file). Or we could just only allow --list-hooks to list certain hooks which are known to the core a priori. I thought I had this in there already? Long time since I've looked, though. As best I can tell (which isn't saying too much =), you can list the functions registered for a particular hook, but I can't find a way to get the names of ALL of the hooks in an entire system and then list all the registrants of each of them. Ah, yeah. There is a utility that fishes them out of the source code but that's not what you want. What we _really_ want is a hook-listing API, so you can write hook-ordering modules, I suspect... Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: cvs commit: httpd-2.0/include http_config.h
Greg Stein wrote: On Fri, Oct 31, 2003 at 10:12:56PM +0100, Sander Striker wrote: From: Brad Nicholes [mailto:[EMAIL PROTECTED] Sent: Friday, October 31, 2003 9:53 PM So what is the best way to resolve this? Currently NetWare won't build. It throws a compiler error in Metrowerks. I can #ifdef it based on the compiler or is there a better way? Revert. I'll live with the warning. Hm. That isn't ideal either. The problem is that we jam a bunch of different types of functions into that one slot. The ideal is probably a union of function pointer types. That doesn't really work either, except with gcc. See the command stuff for Apache modules for that one made as good as we can. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Submitting module
Jeff Trawick wrote: Piras Velandai Thiyagarajan wrote: To better serve the Apache user community for easy integration, it would be nice if during configure compilation option, --with-mod-sun-plugin, that way just be simple effect of compilation, the customers get what they want. I'd expect that many of your customers would not be building Apache but instead would be using a build prepared by their vendor. Also, we don't want to add a module to the Apache distribution which has such a limited purpose. Of course, if we had an implementation of the identity server it might be a different matter. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: module load order
Astrid Keßler wrote: I was just asked again by a user about the load order of modules. While it seems that it is now with Apache2 less important, and also ClearModuleList and AddModule are removed now with Apache2, I think it is at least still important for auth modules. So I searched the manual for any hints, specially about the fact that the last module loaded is the first module in the auth chain This is true for 1.3, but not for 2.0. For 2.0 the module order of the auth modules is undefined. They all register with the same priority at the same hook(s). The sort is done with qsort, which does not guaranty a stable ordering. It can differ from build to build, from libc to libc and from httpd.conf to httpd.conf. This is a real problem if you want to use the Auth*Authoritative directives. This problem has been solved in the 2.1 source tree by introducing the provider mechanism for auth modules. Perhaps my memory is failing me, but I thought the module hooks were sorted with a stable topological sort, not qsort? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
[Fwd: [Spread-users] send text to spread group from command line?]
Would anyone object to me committing this? Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff Hi Ben, I have a patch to httpd-2_0_18-alpha that does what I'm looking for. Don't know the appropriate place to submit it. I've attached it on the off chance direct-to-you is ok. Best, George 1024D/1100A5A0/1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0 error_log.patch
Re: mod_ssl broken
To be completely accurate, the request is: OPTIONS /svn HTTP/1.1 Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Magic in request.c
This patch removes some magic in request.c. I wrote it coz 2.0.28 didn't
actually work at all for me, coz the magic failed.
Somehow the magic was OK again in the snapshot I tried, but I consider
it a bad thing that it exists at all (btw, the whole directory walk I
find completely unreadable, I ought to do something about it).
What do people think?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
--- request.c~ Fri Nov 9 16:54:00 2001
+++ request.c Sun Dec 2 14:36:48 2001
@@ -618,12 +618,14 @@
int res;
char *seg_name;
char *delim;
+ int temp_slash=0;
/* We have no trailing slash, but we sure would appreciate one...
*/
if (sec_idx r-filename[filename_len-1] != '/') {
r-filename[filename_len++] = '/';
r-filename[filename_len] = 0;
+ temp_slash=1;
}
/* Begin *this* level by looking for matching Directory sections
@@ -791,7 +793,7 @@
/* That temporary trailing slash was useful, now drop it.
*/
-if (seg startseg) {
+if (temp_slash) {
r-filename[--filename_len] = '\0';
}
Re: cvs commit: httpd-2.0/modules/loggers mod_log_config.c
[EMAIL PROTECTED] wrote:
brianp 02/01/06 00:01:34
Modified:modules/loggers mod_log_config.c
Log:
Bypass a strdup and an 8KB local variable in the common case where
the logger is using the default time format
Does that really stop the stack space from being allocated? It seems
unlikely to me (I haven't checked).
Cheers,
Ben.
Revision ChangesPath
1.73 +4 -5 httpd-2.0/modules/loggers/mod_log_config.c
Index: mod_log_config.c
===
RCS file: /home/cvs/httpd-2.0/modules/loggers/mod_log_config.c,v
retrieving revision 1.72
retrieving revision 1.73
diff -u -r1.72 -r1.73
--- mod_log_config.c 16 Dec 2001 09:54:14 - 1.72
+++ mod_log_config.c 6 Jan 2002 08:01:34 - 1.73
@@ -450,7 +450,6 @@
{
apr_exploded_time_t xt;
apr_size_t retcode;
-char tstr[MAX_STRING_LEN];
/*
hi. i think getting the time again at the end of the request
@@ -469,7 +468,9 @@
ap_explode_recent_localtime(xt, r-request_time);
#endif
if (a *a) { /* Custom format */
-apr_strftime(tstr, retcode, MAX_STRING_LEN, a, xt);
+char tstr[MAX_STRING_LEN];
+apr_strftime(tstr, retcode, sizeof(tstr), a, xt);
+return apr_pstrdup(r-pool, tstr);
}
else { /* CLF format */
char sign;
@@ -484,13 +485,11 @@
sign = '+';
}
-apr_snprintf(tstr, sizeof(tstr), [%02d/%s/%d:%02d:%02d:%02d %c%.2d%.2d],
+return apr_psprintf(r-pool, [%02d/%s/%d:%02d:%02d:%02d %c%.2d%.2d],
xt.tm_mday, apr_month_snames[xt.tm_mon], xt.tm_year+1900,
xt.tm_hour, xt.tm_min, xt.tm_sec,
sign, timz / (60*60), timz % (60*60));
}
-
-return apr_pstrdup(r-pool, tstr);
}
static const char *log_request_duration(request_rec *r, char *a)
--
http://www.apache-ssl.org/ben.html
Re: cvs commit: apache-1.3/src/os/unix os.c
[EMAIL PROTECTED] wrote: jim 02/05/02 06:28:46 Modified:src/os/unix os.c Log: OK. This is admittedly anal. But the whole idea behind cpp macros is to avoid things like we know NSLINKMODULE_OPTION_NONE is 0 and making such shortcuts as this. This makes it clear what exactly we are setting, and though admittedly verbose, the tradeoff of a few bytes of source is worth it :) Err? But what is the meaning of combining a NONE option with some other? Does it mean we're setting both some and no options? Very Zen! Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: cvs commit: httpd-2.0/modules/ssl mod_ssl.c mod_ssl.h ssl_engine_init.c ssl_engine_io.c ssl_engine_kernel.c ssl_engine_log.c ssl_engine_pphrase.c
[EMAIL PROTECTED] wrote: jerenkrantz02/05/15 16:10:34 Modified:modules/ssl mod_ssl.c mod_ssl.h ssl_engine_init.c ssl_engine_io.c ssl_engine_kernel.c ssl_engine_log.c ssl_engine_pphrase.c Log: Stop using SSL_ADD_SSLERR option in ssl_log() and replace with new ssl_log_ssl_error() function that wraps ap_log_error instead. This begins the migration from ssl_log() - ap_log_error(). Divorcing ourselves from the SSL_ADD_SSLERR option is required to make the next pass easier. Excellent - this was something I'd been planning to do. BTW, speaking of error logging, I've recently noticed that somewhere between forking (at least with prefork) and the server being live, stderr gets detached from the error log (and appears to go to the bit bucket) then reattached later. It doesn't happen when debugging in single process mode, irritatingly. Anyone happen to know why? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PATCH] simplified apachectl that passes through options to httpd
Cliff Woolley wrote: On 23 May 2002, Jeff Trawick wrote: Existing apachectl keywords are still supported for now (except for some alternate spellings of startssl -- whats up with that stuff?). I always assumed it was for Apache-SSL compatibility. Ben? Apache-SSL always has SSL (surprise!), so just plain start suffices. Cheers, Ben.
Re: Is Apache Proxy Half-Duplex?
Ryan Bloom wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Bill Stoddard wrote: This is a variation of the problem Aaron and I were interested in with CGI scripts (and directly related to an open PR against 2.0.36). Unfortunately, I think filters need some more work to make this possible. As Will said, we need to be able to poll/select on both the frontend and backend descriptors and do the right thing. I may be mistaken but I thought the proxy in 1.3 handled this correctly... The v1.3 proxy was always read request then read response, it never did these two simultaneously. Would the changes to the filters be that drastic? We would in theory just have to poll for incoming data (in either direction), then read bridages from the relevant filter stack...? No...? I tried to think through how to do this back in November, when I last touched the proxy. The easiest way to do this, is to add a new read mode to input filters, APR_READ_POLL. Each filter would be responsible for returning any data that it has if called in this mode. If none of the filters in the stack have any data, then the filter that has the socket must return the socket bucket, but it is allowed to keep a copy of the socket itself. The filter_poll call can then use apr_poll to determine which of the sockets have any data. This wouldn't be the cleanest code, but it should work. Seems to me that you really want a apr_poll equivalent that works on bucket brigades - that would make this clean, and could be quite elegant (IMO). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Is Apache Proxy Half-Duplex?
Jeff Trawick wrote: Ben Laurie [EMAIL PROTECTED] writes: Seems to me that you really want a apr_poll equivalent that works on bucket brigades - that would make this clean, and could be quite elegant (IMO). What seems useful (to me) is for apr_poll() to operate on a generic I/O handle (instead of apr_socket_t) and for the APR app to be able to retrieve the generic I/O handle from an APR socket or pipe or whatever. The bucket code could then be able to return a generic I/O handle corresponding to a bucket (extend it for brigades as well). (For some bucket types (e.g., heap) perhaps they always appear readable, or perhaps trying to retrieve the handle indicates that the operation is inappropriat.) Well, you may want that under the hood, but it clearly ain't right for bucket brigades, coz the brigade itself might have data ready. I suppose write brigades will have to say no at some point. Hmm. Non-trivial. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: cvs commit: httpd-2.0/modules/test mod_bucketeer.c
[EMAIL PROTECTED] wrote:
jwoolley2002/05/31 00:43:22
Modified:modules/test mod_bucketeer.c
Log:
we should be copying over all metadata buckets we don't understand, not
just error buckets.
Revision ChangesPath
1.12 +5 -4 httpd-2.0/modules/test/mod_bucketeer.c
Index: mod_bucketeer.c
===
RCS file: /home/cvs/httpd-2.0/modules/test/mod_bucketeer.c,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -d -u -r1.11 -r1.12
--- mod_bucketeer.c 30 May 2002 21:10:19 - 1.11
+++ mod_bucketeer.c 31 May 2002 07:43:22 - 1.12
@@ -141,10 +141,11 @@
continue;
}
-if (AP_BUCKET_IS_ERROR(e)) {
-apr_bucket *err_copy;
-apr_bucket_copy(e, err_copy);
-APR_BRIGADE_INSERT_TAIL(ctx-bb, err_copy);
+if (e-length == 0) {
Looks like magic to me - perhaps wrap it in AP_BUCKET_IS_METADATA()?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
Re: [Bug 9488] - HTTP/0.9 requests spoken on https port returnsHTTP/1.0 response
Cliff Woolley wrote: On Mon, 3 Jun 2002, Ryan Bloom wrote: I was actually just about to look at this problem if you are busy. Go for it... I'm working on something else. Perhaps its just me, but I'm amused this is considered a bug. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [Bug 9488] - HTTP/0.9 requests spoken on https port returnsHTTP/1.0 response
Ryan Bloom wrote: From: Ben Laurie [mailto:[EMAIL PROTECTED]] Cliff Woolley wrote: On Mon, 3 Jun 2002, Ryan Bloom wrote: I was actually just about to look at this problem if you are busy. Go for it... I'm working on something else. Perhaps its just me, but I'm amused this is considered a bug. It's a security hole IMO. The problem is that if you rewrite the URL .*, then the error URL that mod_ssl will be rewritten. This means that you can serve information over HTTP that was supposed to be restricted to HTTPS. Sorry, I don't understand this - seems like you missed a word or two out? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: cvs commit: apache-1.3/src/ap ap_strtol.c
[EMAIL PROTECTED] wrote: jim 2002/06/17 19:07:00 Modified:src/ap ap_strtol.c Log: Just in case, handle LONG_* if limits doesn't have 'em Revision ChangesPath 1.4 +6 -0 apache-1.3/src/ap/ap_strtol.c Index: ap_strtol.c === RCS file: /home/cvs/apache-1.3/src/ap/ap_strtol.c,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- ap_strtol.c 18 Jun 2002 01:19:46 - 1.3 +++ ap_strtol.c 18 Jun 2002 02:07:00 - 1.4 @@ -94,6 +94,12 @@ #include stdlib.h #include ap_ctype.h +#ifndef LONG_MAX +#define LONG_MAX 2147483647 +#endif +#ifndef LONG_MIN +#define LONG_MIN (-2147483647-1) +#endif They're so much more readable in hex: #ifndef LONG_MAX #define LONG_MAX 0x7fffL #endif #ifndef LONG_MIN #define LONG_MIN 0x8000L #endif Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: El-Kabong -- HTML Parser
Jim Jagielski wrote: [EMAIL PROTECTED] wrote: I will make one exception to that statement. If it lands inside of APR-util, under the XML directory, and it is made to work with the XML parser, I can accept that landing spot. As it fits in closer with our goals (I think). Jim, I can't decide if this is what you meant or not. Yes, that is what I meant... side-by-side with the XML stuff under the APR project in apr-util. It makes more sense to me to have a parsers project, since they have a lot in common with each other (and not all that much with other things). But since I'm not going to take on the work of creating such a thing, you can treat that remark with the contempt it deserves :-) Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Style violations
On Sun, Jan 8, 2012 at 4:20 PM, Jim Jagielski j...@jagunet.com wrote: How much is entirely? Do the 80char lines in ap_listen.h, ap_mmn.h, ap_mpm.h, ap_provider.h, ap_regex.h, ap_regkey.h, ap_slotmem.h, http_core.h, http_protocol,h, etc etc etc etc also constitute a rating of entirely? I'd look for more, but my time is better spent fixing things that I find need-to-be-fixed rather than just pointing them out... Was tempted to comment first time round - if Bill objects, why does he not just commit a fix? Not _quite_ as irritating as the demands I used to resist on a regular basis to fix bugs in my commits on platforms I did not have access to, but getting up there. On Jan 5, 2012, at 4:56 PM, William A. Rowe Jr. wrote: modules\proxy\mod_proxy.h entirely violates our 80 column rule, which is particularly offensive owing to the fact that the .h files are the easiest reference outside of doxygen for developers to become familiar with httpd entry points, and aught to be not only editable, but also printable. Would the culprits please clean up before the next 2.4 tag?
Re: Apache httpd 2.4.x on Windows
On Thu, Apr 5, 2012 at 8:34 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 4/5/2012 1:14 PM, Claudio Caldato wrote: Hi William, We need more details in order to be able to figure out what is going on. Any chance that you guys have an isolated repo we can use to investigate this issue? All the notes are in the dev@ list archives this past quarter. People weren't terribly good about keeping the subject lines consistent, though. I'm sure Jim, Steffen or someone would be happy to assemble you the pointers to all the relevant threads. In short mod_ssl expects a blocking socket connection to the client, an apr_sock_t object in APR-speak. Really? I totally haven't kept up, but last I knew mod_ssl used the whole bucket nightmare and did not need blocking connections. If I had time to find you all the scattered threads, I really would find time to debug this myself :)
Backport NPN patch?
Would anyone object to the NPN patch (r1332643) being backported to 2.2 and 2.4?
Re: c conf 2012
On Wed, May 9, 2012 at 6:26 AM, Paul Querna p...@querna.org wrote: Heya, A friend of mine is helping organizing the first C Conf: http://www.cconf.org/ I think it could be a very interesting conference for those of us that still enjoy coding C :-) Not sure I can make it, but your friend might be interested in http://www.links.org/?p=1242 (given Hardening/exploiting modern C code bases). I think it would be great if we could get a few talks submitted about APR and HTTPD too, two projects with a long C history. I personally plan on being there if anyone wants to meet up then -Paul
Re: md5crypt passwords
On Wed, Jun 20, 2012 at 1:25 PM, Nick Edwards nick.z.edwa...@gmail.com wrote: Hello, I posted this to users list last week but no-one bit, so I'm trying here. With md5crypt no longer recommended for use by its author, will Apache soon support sha256/sha512 in basic authentication via MySQL. I understand the apr version is different to plain md5crypt, but it is based on the same thing from what I can tell, so its pointless upgrading our database passwords to use sha512 if Apache's still the weak link. All admin scripts run in perl, and we are currently doing this with apache_md5_crypt($password); using Crypt::PasswdMD5 For Mail and FTP, we are _now_ successfully using crypt($password, '$6$' . $16charsalt) for sha512, be nice if Apache basic auth would too! Apache currently only offers SHA1 which is about as secure (can be read as , as hopeless as) MD5. Can the project devs/team leaders indicate if there are future plans to mnprove the basic auth security methods up to SHA512? This thread is all over the place! So, a summary... * SHA-1 is not as broken as MD5 - no way to generate collisions has been found that is practical. * MD5 is still pre-image resistant even though it is possible to generate collisions. This means that repeated applications of MD5 are also pre-image resistant. * The threat against md5crypt is the same as it has always been: rainbow tables. The current attacks have not changed this. * htpasswd uses an 8 byte salt with 6 bits per byte. So, a rainbow table will have 2^48 entries per password. Assuming you can somehow manage 1 byte per entry, that's still nearly 300 TB per password. So, I'd say there's no need for panic, but there's also no reason that I can see to not move to a more modern scheme. Then the question is: what scheme? Here are some design criteria I think would be useful. 1. Use something from the SHA-2 family - SHA-512 would seem fine to me. 2. Use a very large salt - disk space is not at a premium for password stores! 3. Use quite a lot of rounds,. 4. Use something that is hard to optimise in hardware (ideally).
Re: md5crypt passwords
On Thu, Jun 21, 2012 at 10:53 AM, Issac Goldstand mar...@beamartyr.net wrote: On 21/06/2012 12:40, Ben Laurie wrote: 4. Use something that is hard to optimise in hardware (ideally). And what about massive sites that need the crypto HW to manage the concurrent logins? I have never come across a site where login causes significant load. They may exist, but I figure they can do their own thing for passwords... Yes, you're making it harder on the hackers, but also potentially on our users. ...Or did I just put my foot in my crypto-clueless-mouth? Issac
Why RFC 5878 matters...
I'm working on Certificate Transparency
(http://www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf).
TL;DNR: CAs are a mess, and we need to do something about it.
RFC 5878 adds a TLS extension which permits a server to send extra
authorisation information along with the certificate chain. This is
a general purpose mechanism which can be used to augment information
in the certificate. In CT we use it to send a proof from the log
server(s) that the certificate is included in the log.
However, the support I have added is not specific to CT, it will allow
you to configure any appropriate data to be sent in the extension.
One of the barriers to CT adoption is that it requires a server
software change. This change removes that barrier from future similar
schemes - and lowers it for CT, since we may yet change our proof
formats or other protocol elements, and in future that will just be a
different file in the configuration.
So, I'd like to urge committers to add their +1 to my patch.
It does 3 things, btw:
1. Add new config directives, SSL{RSA,DSA,EC}AuthzFile, which specify
a file to be sent along with the certificate of corresponding type.
2. Bail out if one of these directives is active and the linked
version of OpenSSL does not support RFC 5878.
3. Allow you to configure a development version of OpenSSL for testing
(not in 2.2, this still has to be manually tweaked).
