Re: Bug using authnz_ldap_module with Microsoft LDAP SDK and ldaps (secure ldap)?
On Mon, Mar 4, 2013 at 3:34 PM, Steffen wrote: > On your request a patched mod_ldap.so available at AL post, > with following changes in ldap_util.c : Thanks!
Re: Bug using authnz_ldap_module with Microsoft LDAP SDK and ldaps (secure ldap)?
On your request a patched mod_ldap.so available at AL post,
with following changes in ldap_util.c :
rc = apr_ldap_ssl_init(p,
NULL,
0,
&(result_err));
- if (APR_SUCCESS == rc) {
+ if (APR_SUCCESS == rc && !apr_is_empty_array(st->global_certs)) {
rc = apr_ldap_set_option(ptemp, NULL, APR_LDAP_OPT_TLS_CERT,
(void *)st->global_certs, &(result_err));
}
Steffen
-Original Message-
From: Eirik Lygre
Sent: Monday, March 4, 2013 8:15 PM Newsgroups: gmane.comp.apache.devel
To: dev@httpd.apache.org
Subject: Re: Bug using authnz_ldap_module with Microsoft LDAP SDK and ldaps
(secure ldap)?
Eirik Lygre wrote
Eirik Lygre wrote
Eric Covener wrote
On Thu, Feb 28, 2013 at 11:12 AM, Eirik Lygre <
eirik.lygre@
> wrote:
seems to make sense, were you able to test the mod_ldap side of the
change, or is the rebuild a problem?
The number of moving parts needed to build it all was a bit daunting, so
it's all theory, I'm afraid. If anybody with a working build setup could
add the required if-test and build a version, I'd be more than willing to
test and verify it all.
I have entered an issue in the bug database, available as
https://issues.apache.org/bugzilla/show_bug.cgi?id=54626.
Eirik
Given that I'm unable to build it myself, is there anything I can do to help
move this issue forward and get it resolved?
Eirik
--
View this message in context:
http://apache-http-server.18135.n6.nabble.com/Bug-using-authnz-ldap-module-with-Microsoft-LDAP-SDK-and-ldaps-secure-ldap-tp5003960p5004104.html
Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: I do not like sprint downloading my information
On Mon, Mar 4, 2013 at 1:55 PM, Diana Andrews wrote: > Signed, > Diana j.Andrews I'm not sure what that has to do with Apache httpd. -- Sent from my Game Boy.
Re: Bug using authnz_ldap_module with Microsoft LDAP SDK and ldaps (secure ldap)?
Eirik Lygre wrote > > Eirik Lygre wrote >> >> Eric Covener wrote >>> On Thu, Feb 28, 2013 at 11:12 AM, Eirik Lygre < >>> eirik.lygre@ >>> > wrote: >>> seems to make sense, were you able to test the mod_ldap side of the >>> change, or is the rebuild a problem? >> The number of moving parts needed to build it all was a bit daunting, so >> it's all theory, I'm afraid. If anybody with a working build setup could >> add the required if-test and build a version, I'd be more than willing to >> test and verify it all. > I have entered an issue in the bug database, available as > https://issues.apache.org/bugzilla/show_bug.cgi?id=54626. > > Eirik Given that I'm unable to build it myself, is there anything I can do to help move this issue forward and get it resolved? Eirik -- View this message in context: http://apache-http-server.18135.n6.nabble.com/Bug-using-authnz-ldap-module-with-Microsoft-LDAP-SDK-and-ldaps-secure-ldap-tp5003960p5004104.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
mod_cache with Cache-Control no-cache= or private=
Hi, I've been working on a patch for mod_cache to deal (fully) with the response header Cache-Control and the no-cache= or private= directives. This "feature" is mainly used with the Set-Cookie header, and allows the origin server to control the caching of that particular header. Although the code is already there to detect their usage with a header, mod_cache still handle these directives as if no header was specified. That is, "stale entity causing revalidation" [by the origin server]. The RFC-2616 (14.9.1 What is Cacheable) says this about the no-cache= directive : If the no-cache directive does specify one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response. For what I understand, mod_cache is allowed to serve its cached entity (though without the specified header(s)). mod_cache already provides the configuration directive CacheIgnoreHeaders to prevent the specified headers from being cached, but this gives no control to the origin server. The attached patch works with trunk and 2.4 (I've got one for 2.2 too, which is the version I use, but I doubt such a feature would be merged into it...). Note that the patch also fixes what seems to be an unfortunate replacement of the tab character (^V) with spaces in the CACHE_SEPARATOR macro definition. Thanks for your feedbacks, regards, Yann. cache_util-trunk.patch Description: Binary data
RE: [patch] Fix cross-user symlink race condition vulnerability
> If you would like more information on the exploit itself, please let me > know. I have a proof of concept that is able to hit the exploit with > 100% success. Hi Eric, I'm trying to test this patch and would love to know how you're able to duplicate this on-demand. Thanks, Jason
