VPATH build breaks with ap_ugly_hack in CVS httpd-2.0

[Nicholas Riley]

Hi,

I was just updating my httpd-2.0 CVS after a couple of months of
inactivity and it failed linking httpd with the error:

ld: Undefined symbols:
_ap_ugly_hack
make[1]: *** [httpd] Error 1
make: *** [all-recursive] Error 1

The problem appears to be that exports.c is not properly referenced,
but trying the naive fix (removing the path specifier) gives me a
symlink from exports.lo -> exports.lo.

At this point I gave up and went back to a non-VPATH build, but this
is rather sub-optimal.  It worked before, it would be nice if it
worked again.

Thanks,

-- 
=Nicholas Riley <[EMAIL PROTECTED]> | 
Pablo Research Group, Department of Computer Science and
  Medical Scholars Program, University of Illinois at Urbana-Champaign

SSL Upgrade support.

[rbb]

Just a heads up.  I wrote SSL Upgrade support this weekend for Apache
2.0.  In my (currently) limited testing, things look pretty good.  We
currently respond to all requests correctly, and I think I have the SSL
filters being inserted properly.  However, there are no clients that I
know of that support this feature yet.  My hope was to have time to add it
to Neon this weekend, but it didn't happen.  I won't commit the Apache
code until I can test it with a client, so if anybody wants to
help me implement the client side, or if anybody knows of any clients that
already support this, please let me know.

Ryan

___
Ryan Bloom  [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---

Re: httpd-2.0.43-alpha candidates available...

[gregames]

"William A. Rowe, Jr." wrote:
> 
> for testing from http://httpd.apache.org/dev/dist/ in your preferred
> .tar.gz, .tar.Z or -win32-src.zip format (-win32-src.zip containing
> the msvc makefiles.)

It's been running for about 20 minutes on daedalus - looks fine.

Greg

Re: [PATCH] Deny when reverse lookup fails

[Justin Erenkrantz]

--On Friday, October 4, 2002 10:13 AM -0400 Joshua Slive <[EMAIL PROTECTED]> 
wrote:

> If I understand you correctly, that would be a major change to current
> behavior.  I believe that people expect a configuration like
>
> deny from .badguy.com
>
> to allow access from unknown IP addresses (IP addresses that have no
> reverse lookup).  Obviously, this is not at all secure, but that is how
> it has always been, and it is the way I would expect it to work.

Yes and no.  If I control badguy.com and know that you're denying me based 
on that, I could remove the reverse mapping from my domain and then I can 
get in.  So, yes, host-based denial is insecure and has almost no hope of 
true success.

Perhaps we could create a config option that allows for double reverse 
failures on denials to proceed.  But, I think it is worth it to reevaluate 
what we're doing now...  -- justin

Re: dev Digest 5 Oct 2002 17:30:59 -0000 Issue 1062

[Martin Kutschker]

[EMAIL PROTECTED] writes on 
Sat, 05 Oct 2002 19:30:59 +0200 (METDST):

> dev Digest 5 Oct 2002 17:30:59 - Issue 1062
> 
> Topics (messages 33776 through 33793):
> 
> Re: RLimitNPROC behaviour question
> 33776 by: Joshua Slive
> 33777 by: André Malo
> 33780 by: André Malo
> 33781 by: E. FROUNI
> 
> [Security Release] Apache HTTP Server 2.0.43
> 33778 by: William A. Rowe, Jr.
> 33779 by: William A. Rowe, Jr.
> 33782 by: Andreas Hasenack
> 
> [PATCH] Deny when reverse lookup fails
> 33783 by: Justin Erenkrantz
> 33787 by: Joshua Slive
> 
> recommended openssl version for 2.0.43
> 33784 by: Günter Knauf
> 33785 by: Dirk-Willem van Gulik
> 33786 by: Thom May
> 
> Bug handling survey - 80:20 rule
> 33788 by: Gunes Koru
> 
> Re: DO NOT REPLY [Bug 9181] - Unable to set headers on non-2XX
> responses.
> 33789 by: rbb.apache.org
> 
> auth_ldap on Win32
> 33790 by: Günter Knauf
> 
> mod_logio in patches area
> 33791 by: Bojan Smojver
> 33792 by: Oden Eriksson
> 
> Re: Build on AIX fails
> 33793 by: Jeff Trawick
> 
> Administrivia:
> 
> To subscribe to the digest, e-mail:
> <[EMAIL PROTECTED]>
> 
> To unsubscribe from the digest, e-mail:
> <[EMAIL PROTECTED]>
> 
> To post to the list, e-mail:
> <[EMAIL PROTECTED]>
> 
> 
>
> --
> 
> == 33776 ==
> 
> Sorry, that message is not in the archive.


And so on. What happened to the messages?

Masi