Ha!
*) mod_logio: Log time-to-first-byte via %^FB trunk patch: http://svn.apache.org/r1671918 2.4.x patch: trunk works (modulo CHANGES) +1: covener + .mine + trawick: r1673113 should be added to the proposal +=== ylavic: +1 with http://svn.apache.org/r1673113 + .r1673770
Re: Ha!
Done by Eric :) On Wed, Apr 15, 2015 at 4:04 PM, Jeff Trawick traw...@gmail.com wrote: *) mod_logio: Log time-to-first-byte via %^FB trunk patch: http://svn.apache.org/r1671918 2.4.x patch: trunk works (modulo CHANGES) +1: covener + .mine + trawick: r1673113 should be added to the proposal +=== ylavic: +1 with http://svn.apache.org/r1673113 + .r1673770
namespacing in mod_ssl
A few months ago, OpenBSD's LibreSSL added a new function
called SSL_CTX_use_certificate_chain().
This unexpectedly broke the build of Apache's mod_ssl which defines
a function of the same name. In OpenBSD this was worked around by
patching mod_ssl, renaming the clashing function.
Since then LibreSSL has renamed to SSL_CTX_use_certificate_chain_mem().
This resolved the immediate problem and mod_ssl patches could be dropped.
However, the actual issue here is that mod_ssl is squatting the SSL_ namespace.
Historically this may have made sense (it seems mod_ssl and OpenSSL have
shared history/authors). Bill Rowe suggested to try moving mod_ssl's
functions into the ap_ namespace to avoid such clashes in the future.
I have verified that no undefined references or undeclared symbols
are reported by gcc during the build with this diff.
I have tested startup of a httpd with mod_ssl loaded.
Additional testing is appreciated.
I'm not sure how README.dsov.ps should be regenerated.
It contains a refence to SSL_get_app_data2().
For now I've only updated the .dsov.fig file.
Index: modules/ssl/README.dsov.fig
===
--- modules/ssl/README.dsov.fig (revision 1673798)
+++ modules/ssl/README.dsov.fig (working copy)
@@ -339,7 +339,7 @@
4 0 0 200 0 20 8 0. 4 90 465 11745 4770 -method\001
4 0 0 200 0 20 8 0. 4 120 1665 9945 6480 X509_STORE_CTX_get_app_data()\001
4 0 0 200 0 20 8 0. 4 120 1215 10980 6705 SSL_CTX_get_cert_store()\001
-4 0 0 200 0 20 8 0. 4 120 1020 8280 5130 SSL_get_app_data2()\001
+4 0 0 200 0 20 8 0. 4 120 1020 8280 5130 ap_SSL_get_app_data2()\001
4 0 0 100 0 18 20 0. 4 270 1290 10710 7605 OpenSSL\001
4 0 0 100 0 18 12 0. 4 180 720 10710 7785 [Crypto]\001
4 0 0 100 0 18 20 0. 4 270 1290 10935 3645 OpenSSL\001
Index: modules/ssl/mod_ssl.c
===
--- modules/ssl/mod_ssl.c (revision 1673798)
+++ modules/ssl/mod_ssl.c (working copy)
@@ -570,7 +570,7 @@
}
SSL_set_app_data(ssl, c);
-SSL_set_app_data2(ssl, NULL); /* will be request_rec */
+ap_SSL_set_app_data2(ssl, NULL); /* will be request_rec */
sslconn-ssl = ssl;
Index: modules/ssl/ssl_engine_init.c
===
--- modules/ssl/ssl_engine_init.c (revision 1673798)
+++ modules/ssl/ssl_engine_init.c (working copy)
@@ -148,12 +148,12 @@
apr_status_t rv;
apr_array_header_t *pphrases;
-if (SSLeay() SSL_LIBRARY_VERSION) {
+if (SSLeay() AP_SSL_LIBRARY_VERSION) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, base_server, APLOGNO(01882)
Init: this version of mod_ssl was compiled against
a newer library (%s, version currently loaded is %s)
- may result in undefined or erroneous behavior,
- SSL_LIBRARY_TEXT, SSLeay_version(SSLEAY_VERSION));
+ AP_SSL_LIBRARY_TEXT, SSLeay_version(SSLEAY_VERSION));
}
/* We initialize mc-pid per-process in the child init,
@@ -242,7 +242,7 @@
#endif
ap_log_error(APLOG_MARK, APLOG_INFO, 0, s, APLOGNO(01883)
- Init: Initialized %s library, SSL_LIBRARY_NAME);
+ Init: Initialized %s library, AP_SSL_LIBRARY_NAME);
/*
* Seed the Pseudo Random Number Generator (PRNG)
@@ -348,7 +348,7 @@
*/
ssl_add_version_components(p, base_server);
-SSL_init_app_data2_idx(); /* for SSL_get_app_data2() at request time */
+ap_SSL_init_app_data2_idx(); /* for ap_SSL_get_app_data2() at request time
*/
init_dh_params();
@@ -871,9 +871,9 @@
}
}
-n = SSL_CTX_use_certificate_chain(mctx-ssl_ctx,
- (char *)chain,
- skip_first, NULL);
+n = ap_SSL_CTX_use_certificate_chain(mctx-ssl_ctx,
+ (char *)chain,
+ skip_first, NULL);
if (n 0) {
ap_log_error(APLOG_MARK, APLOG_EMERG, 0, s, APLOGNO(01903)
Failed to configure CA certificate chain!);
@@ -946,7 +946,7 @@
* Some information about the certificate(s)
*/
-if (SSL_X509_getBC(cert, is_ca, pathlen)) {
+if (ap_SSL_X509_getBC(cert, is_ca, pathlen)) {
if (is_ca) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s, APLOGNO(01906)
%s server certificate is a CA certificate
@@ -961,8 +961,8 @@
}
}
-if (SSL_X509_match_name(ptemp, cert, (const char *)s-server_hostname,
-TRUE, s) == FALSE) {
+if (ap_SSL_X509_match_name(ptemp, cert, (const char *)s-server_hostname,
+ TRUE, s) == FALSE) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s, APLOGNO(01909)
%s server certificate
Re: svn commit: r1672014 - in /httpd/httpd/trunk: CHANGES server/config.c
On 14.04.2015 06:54, Kaspar Brand wrote:
On 13.04.2015 22:05, Ruediger Pluem wrote:
Shouldn't we only do that in case that vit-log.level is set to
main_server-log.level?
Don't we lose the configuration done by the user for this particular host
otherwise?
Yes, you're right - thanks for the review. It also noticed this in the
meantime, and when I tried to come up with a fix, more special cases
were turning up (whether main_server-log.level is still at
DEFAULT_LOGLEVEL might also have to be taken into account).
Hopefully I'll find time for more closely examining this tomorrow.
Otherwise I will revert r1672014, as it is clearly not a complete
solution yet.
Reverted r1672014. After more digging, I think there's no practical way
to base the decision whether to reset on the current value of
virt-log.level when reaching ap_fixup_virtual_hosts - too many
conceivable combinations of global LogLevel vs. per-vhost LogLevel (and
the order they appear in the config). Extending the ap_logconf struct
seems unavoidable if the approach with adjustments in
ap_init_virtual_host/ap_fixup_virtual_hosts is the right one.
Another idea would be to apply the default log level in log_error_core()
when we encounter APLOG_UNSET, as illustrated by the attached patch.
Maybe doing this check in each log_error_core() invocation adds too much
overhead, given that it's actually just addressing an issue which occurs
at startup/reload?
The other option to fix the problem which originally triggered this
investigation would be to simply replace cmd-server in
ssl_engine_config.c:836 with NULL, though it would only fix this
particular case, and not help with other places with the same underlying
problem.
Kaspar
Index: include/http_log.h
===
--- include/http_log.h (revision 1673835)
+++ include/http_log.h (working copy)
@@ -128,6 +128,8 @@ extern C {
*/
#define APLOG_NO_MODULE -1
+#define APLOG_UNSET (APLOG_NO_MODULE - 1)
+
#ifdef __cplusplus
/**
* C++ modules must invoke ::APLOG_USE_MODULE or ::AP_DECLARE_MODULE in
Index: server/config.c
===
--- server/config.c (revision 1673838)
+++ server/config.c (working copy)
@@ -52,7 +52,6 @@
#include util_varbuf.h
#include mpm_common.h
-#define APLOG_UNSET (APLOG_NO_MODULE - 1)
/* we know core's module_index is 0 */
#undef APLOG_MODULE_INDEX
#define APLOG_MODULE_INDEX AP_CORE_MODULE_INDEX
Index: server/log.c
===
--- server/log.c(revision 1673835)
+++ server/log.c(working copy)
@@ -1075,6 +1075,11 @@ static void log_error_core(const char *file, int l
int configured_level = r ? ap_get_request_module_loglevel(r,
module_index):
c ? ap_get_conn_server_module_loglevel(c, s,
module_index) :
ap_get_server_module_loglevel(s,
module_index);
+
+/* Temporarily adjust to the default if the level hasn't been set yet
*/
+if (configured_level == APLOG_UNSET)
+configured_level = ap_default_loglevel;
+
/*
* If we are doing normal logging, don't log messages that are
* above the module's log level unless it is a startup/shutdown notice
Re: svn commit: r1673850 - /httpd/httpd/branches/2.4.x/STATUS
On Wed, Apr 15, 2015 at 6:25 PM, traw...@apache.org wrote: Author: trawick Date: Wed Apr 15 16:25:47 2015 New Revision: 1673850 URL: http://svn.apache.org/r1673850 Log: one pear-flavored drink, one vote Can't wait for the next ones :)
check for RAND_egd at configure time
LibreSSL does not provide the RAND_egd() function.
This patch adds a configure check to allow building mod_ssl with LibreSSL.
Index: modules/ssl/config.m4
===
--- modules/ssl/config.m4 (revision 1673798)
+++ modules/ssl/config.m4 (working copy)
@@ -44,6 +44,12 @@
# structure, so ask libtool to hide everything else:
APR_ADDTO(MOD_SSL_LDADD, [-export-symbols-regex ssl_module])
fi
+
+have_rand_egd=no
+AC_CHECK_LIB(crypto, RAND_egd, [have_rand_egd=yes])
+if test $have_rand_egd = yes; then
+AC_DEFINE([HAVE_RAND_EGD], [1], [Define if RAND_egd exists.])
+fi
else
enable_ssl=no
fi
Index: modules/ssl/ssl_engine_rand.c
===
--- modules/ssl/ssl_engine_rand.c (revision 1673798)
+++ modules/ssl/ssl_engine_rand.c (working copy)
@@ -86,6 +86,7 @@
nDone += ssl_rand_feedfp(p, fp, pRandSeed-nBytes);
ssl_util_ppclose(s, p, fp);
}
+#ifdef HAVE_RAND_EGD
else if (pRandSeed-nSrc == SSL_RSSRC_EGD) {
/*
* seed in contents provided by the external
@@ -95,6 +96,7 @@
continue;
nDone += n;
}
+#endif
else if (pRandSeed-nSrc == SSL_RSSRC_BUILTIN) {
struct {
time_t t;
Re: svn commit: r1673904 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS docs/manual/mod/mod_logio.xml modules/loggers/mod_logio.c
Hi, compatibility note is missing in the doc. BTW, what is the reason of the LogIOTrackTTFB directive? No impact on performance if %^FB is not needed? CJ Le 15/04/2015 19:59, cove...@apache.org a écrit : Author: covener Date: Wed Apr 15 17:59:42 2015 New Revision: 1673904 URL: http://svn.apache.org/r1673904 Log: Merge r1671918, r1673113 from trunk: allow time to first byte (of response headers) to be logged by mod_logio. mod_logio was just a conveninent place to do this w/o writing a new filter or complicating an existing important one. Use 'unsigned int' in bitfield Modified: httpd/httpd/branches/2.4.x/ (props changed) httpd/httpd/branches/2.4.x/CHANGES httpd/httpd/branches/2.4.x/STATUS httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.xml httpd/httpd/branches/2.4.x/modules/loggers/mod_logio.c Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.xml URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.xml?rev=1673904r1=1673903r2=1673904view=diff == --- httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.xml (original) +++ httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.xml Wed Apr 15 17:59:42 2015 @@ -72,6 +72,12 @@ tdBytes transferred (received and sent), including request and headers, cannot be zero. This is the combination of %I and %O.br / Available in Apache 2.4.7 and later/td/tr + +trtdcode%^FB/code/td +tdDelay in microseconds between when the request arrived and the +first byte of the response headers are written. Only available if +directiveLogIOTrackTTFB/directive is set to ON. +/td/tr /table pUsually, the functionality is used like this:/p @@ -83,4 +89,21 @@ /dl /section +directivesynopsis +nameLogIOTrackTTFB/name +descriptionEnable tracking of time to first byte (TTFB)/description +syntaxLogIOTrackTTFB ON|OFF/syntax +defaultLogIOTrackTTFB OFF/default +contextlistcontextserver config/contextcontextvirtual host/context +contextdirectory/contextcontext.htaccess/context/contextlist +overridenone/override + +usage +pThis directive configures whether this module tracks the delay +between the request being read and the first byte of the response +headers being written. The resulting value may be logged with the +code%^FB/code format./p +/usage +/directivesynopsis + /modulesynopsis
Re: svn commit: r1673904 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS docs/manual/mod/mod_logio.xml modules/loggers/mod_logio.c
Thanks for the review On Wed, Apr 15, 2015 at 1:21 PM, Marion Christophe JAILLET christophe.jail...@wanadoo.fr wrote: compatibility note is missing in the doc. r1673924. BTW, what is the reason of the LogIOTrackTTFB directive? No impact on performance if %^FB is not needed? Unfortunately it needs to call apr_time_now() (gettimeofday()) before it is called back by mod_log_config to be able to track the time. I didn't want to add another apr_time_now() in the request path, but I don't know how practical of a concern that might be.
Re: namespacing in mod_ssl
On Apr 15, 2015, at 3:54 PM, Jeff Trawick traw...@gmail.com wrote: IMO it would be appropriate to instead go one by one and make sure we're using an appropriate name to begin with for these functions that are squatting the SSL namespace, instead of making these often-bewildering names ugly and (still) bewildering. +1 Best, Victor -- Victor J. Orlikowski victor.j.orlikow...@alumni.duke.edu
Re: svn commit: r1673940 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS modules/ssl/ssl_util_ssl.c
Am 15.04.2015 um 21:49 schrieb cove...@apache.org: Author: covener Date: Wed Apr 15 19:49:31 2015 New Revision: 1673940 URL: http://svn.apache.org/r1673940 Log: Merge r1666297 from trunk: ssl_util: Fix possible crash (free = OPENSSL_free) and error path leaks when checking the server certificate constraints (SSL_X509_getBC()). Modified: httpd/httpd/branches/2.4.x/ (props changed) httpd/httpd/branches/2.4.x/CHANGES httpd/httpd/branches/2.4.x/STATUS httpd/httpd/branches/2.4.x/modules/ssl/ssl_util_ssl.c Modified: httpd/httpd/branches/2.4.x/CHANGES URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1673940r1=1673939r2=1673940view=diff == --- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original) +++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Wed Apr 15 19:49:31 2015 @@ -12,6 +12,13 @@ Changes with Apache 2.4.13 calls r:wsupgrade() can cause a child process crash. [Edward Lu Chaosed0 gmail.com] + *) mod_ssl: Fix possible crash when loading server certificate constraints. + PR 57694. [Paul Spangler paul.spangler ni com, Yann Ylavic] + + *) core, modules: Avoid error response/document handling by the core if some + handler or input filter already did it while reading the request (causing + a double response body). [Yann Ylavic] + *) build: Don't load mod_cgi and mod_cgid in the default configuration if they're both built. [olli hauer ohauer gmx.de] Is the second (core) entry intentional or a merge error? Regards, Rainer
Re: namespacing in mod_ssl
On 04/15/2015 11:36 AM, Stefan Sperling wrote:
A few months ago, OpenBSD's LibreSSL added a new function
called SSL_CTX_use_certificate_chain().
This unexpectedly broke the build of Apache's mod_ssl which defines
a function of the same name. In OpenBSD this was worked around by
patching mod_ssl, renaming the clashing function.
Since then LibreSSL has renamed to SSL_CTX_use_certificate_chain_mem().
This resolved the immediate problem and mod_ssl patches could be dropped.
However, the actual issue here is that mod_ssl is squatting the SSL_ namespace.
Historically this may have made sense (it seems mod_ssl and OpenSSL have
shared history/authors). Bill Rowe suggested to try moving mod_ssl's
functions into the ap_ namespace to avoid such clashes in the future.
IMO it would be appropriate to instead go one by one and make sure we're
using an appropriate name to begin with for these functions that are
squatting the SSL namespace, instead of making these often-bewildering
names ugly and (still) bewildering.
AP_SSL_LIBRARY_NAME is very appropriate, but ap_SSL_set_app_data2 is the
wrong fix.
I have verified that no undefined references or undeclared symbols
are reported by gcc during the build with this diff.
I have tested startup of a httpd with mod_ssl loaded.
Additional testing is appreciated.
I'm not sure how README.dsov.ps should be regenerated.
It contains a refence to SSL_get_app_data2().
For now I've only updated the .dsov.fig file.
Index: modules/ssl/README.dsov.fig
===
--- modules/ssl/README.dsov.fig (revision 1673798)
+++ modules/ssl/README.dsov.fig (working copy)
@@ -339,7 +339,7 @@
4 0 0 200 0 20 8 0. 4 90 465 11745 4770 -method\001
4 0 0 200 0 20 8 0. 4 120 1665 9945 6480 X509_STORE_CTX_get_app_data()\001
4 0 0 200 0 20 8 0. 4 120 1215 10980 6705 SSL_CTX_get_cert_store()\001
-4 0 0 200 0 20 8 0. 4 120 1020 8280 5130 SSL_get_app_data2()\001
+4 0 0 200 0 20 8 0. 4 120 1020 8280 5130 ap_SSL_get_app_data2()\001
4 0 0 100 0 18 20 0. 4 270 1290 10710 7605 OpenSSL\001
4 0 0 100 0 18 12 0. 4 180 720 10710 7785 [Crypto]\001
4 0 0 100 0 18 20 0. 4 270 1290 10935 3645 OpenSSL\001
Index: modules/ssl/mod_ssl.c
===
--- modules/ssl/mod_ssl.c (revision 1673798)
+++ modules/ssl/mod_ssl.c (working copy)
@@ -570,7 +570,7 @@
}
SSL_set_app_data(ssl, c);
-SSL_set_app_data2(ssl, NULL); /* will be request_rec */
+ap_SSL_set_app_data2(ssl, NULL); /* will be request_rec */
sslconn-ssl = ssl;
Index: modules/ssl/ssl_engine_init.c
===
--- modules/ssl/ssl_engine_init.c (revision 1673798)
+++ modules/ssl/ssl_engine_init.c (working copy)
@@ -148,12 +148,12 @@
apr_status_t rv;
apr_array_header_t *pphrases;
-if (SSLeay() SSL_LIBRARY_VERSION) {
+if (SSLeay() AP_SSL_LIBRARY_VERSION) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, base_server, APLOGNO(01882)
Init: this version of mod_ssl was compiled against
a newer library (%s, version currently loaded is %s)
- may result in undefined or erroneous behavior,
- SSL_LIBRARY_TEXT, SSLeay_version(SSLEAY_VERSION));
+ AP_SSL_LIBRARY_TEXT, SSLeay_version(SSLEAY_VERSION));
}
/* We initialize mc-pid per-process in the child init,
@@ -242,7 +242,7 @@
#endif
ap_log_error(APLOG_MARK, APLOG_INFO, 0, s, APLOGNO(01883)
- Init: Initialized %s library, SSL_LIBRARY_NAME);
+ Init: Initialized %s library, AP_SSL_LIBRARY_NAME);
/*
* Seed the Pseudo Random Number Generator (PRNG)
@@ -348,7 +348,7 @@
*/
ssl_add_version_components(p, base_server);
-SSL_init_app_data2_idx(); /* for SSL_get_app_data2() at request time */
+ap_SSL_init_app_data2_idx(); /* for ap_SSL_get_app_data2() at request time
*/
init_dh_params();
@@ -871,9 +871,9 @@
}
}
-n = SSL_CTX_use_certificate_chain(mctx-ssl_ctx,
- (char *)chain,
- skip_first, NULL);
+n = ap_SSL_CTX_use_certificate_chain(mctx-ssl_ctx,
+ (char *)chain,
+ skip_first, NULL);
if (n 0) {
ap_log_error(APLOG_MARK, APLOG_EMERG, 0, s, APLOGNO(01903)
Failed to configure CA certificate chain!);
@@ -946,7 +946,7 @@
* Some information about the certificate(s)
*/
-if (SSL_X509_getBC(cert, is_ca, pathlen)) {
+if (ap_SSL_X509_getBC(cert, is_ca, pathlen)) {
if (is_ca) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s, APLOGNO(01906)
%s
Re: svn commit: r1673940 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS modules/ssl/ssl_util_ssl.c
inadvertent -- thanks for the catch. On Wed, Apr 15, 2015 at 2:54 PM, Rainer Jung rainer.j...@kippdata.de wrote: Am 15.04.2015 um 21:49 schrieb cove...@apache.org: Author: covener Date: Wed Apr 15 19:49:31 2015 New Revision: 1673940 URL: http://svn.apache.org/r1673940 Log: Merge r1666297 from trunk: ssl_util: Fix possible crash (free = OPENSSL_free) and error path leaks when checking the server certificate constraints (SSL_X509_getBC()). Modified: httpd/httpd/branches/2.4.x/ (props changed) httpd/httpd/branches/2.4.x/CHANGES httpd/httpd/branches/2.4.x/STATUS httpd/httpd/branches/2.4.x/modules/ssl/ssl_util_ssl.c Modified: httpd/httpd/branches/2.4.x/CHANGES URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1673940r1=1673939r2=1673940view=diff == --- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original) +++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Wed Apr 15 19:49:31 2015 @@ -12,6 +12,13 @@ Changes with Apache 2.4.13 calls r:wsupgrade() can cause a child process crash. [Edward Lu Chaosed0 gmail.com] + *) mod_ssl: Fix possible crash when loading server certificate constraints. + PR 57694. [Paul Spangler paul.spangler ni com, Yann Ylavic] + + *) core, modules: Avoid error response/document handling by the core if some + handler or input filter already did it while reading the request (causing + a double response body). [Yann Ylavic] + *) build: Don't load mod_cgi and mod_cgid in the default configuration if they're both built. [olli hauer ohauer gmx.de] Is the second (core) entry intentional or a merge error? Regards, Rainer -- Eric Covener cove...@gmail.com
Re: namespacing in mod_ssl
On 04/15/2015 02:54 PM, Jeff Trawick wrote:
On 04/15/2015 11:36 AM, Stefan Sperling wrote:
A few months ago, OpenBSD's LibreSSL added a new function
called SSL_CTX_use_certificate_chain().
This unexpectedly broke the build of Apache's mod_ssl which defines
a function of the same name. In OpenBSD this was worked around by
patching mod_ssl, renaming the clashing function.
Since then LibreSSL has renamed to SSL_CTX_use_certificate_chain_mem().
This resolved the immediate problem and mod_ssl patches could be
dropped.
However, the actual issue here is that mod_ssl is squatting the SSL_
namespace.
Historically this may have made sense (it seems mod_ssl and OpenSSL have
shared history/authors). Bill Rowe suggested to try moving mod_ssl's
functions into the ap_ namespace to avoid such clashes in the future.
IMO it would be appropriate to instead go one by one and make sure
we're using an appropriate name to begin with for these functions that
are squatting the SSL namespace, instead of making these
often-bewildering names ugly and (still) bewildering.
AP_SSL_LIBRARY_NAME is very appropriate, but ap_SSL_set_app_data2 is
the wrong fix.
As far as the ap_prefix advice received: I don't see any ap_-prefixed
mod_ssl external symbols.
mod_ssl uses ssl_ prefixes heavily (and foo_ prefix for mod_foo in
general is common). For functions and types (i.e., stuff generally
expressed in lower case), a simple ssl_ prefix instead of ap_SSL_
prefix should work and not look so different than existing mod_ssl code.
Perhaps some of the active mod_ssl devs/maintainers will speak up ;)
I have verified that no undefined references or undeclared symbols
are reported by gcc during the build with this diff.
I have tested startup of a httpd with mod_ssl loaded.
Additional testing is appreciated.
I'm not sure how README.dsov.ps should be regenerated.
It contains a refence to SSL_get_app_data2().
For now I've only updated the .dsov.fig file.
Index: modules/ssl/README.dsov.fig
===
--- modules/ssl/README.dsov.fig(revision 1673798)
+++ modules/ssl/README.dsov.fig(working copy)
@@ -339,7 +339,7 @@
4 0 0 200 0 20 8 0. 4 90 465 11745 4770 -method\001
4 0 0 200 0 20 8 0. 4 120 1665 9945 6480
X509_STORE_CTX_get_app_data()\001
4 0 0 200 0 20 8 0. 4 120 1215 10980 6705
SSL_CTX_get_cert_store()\001
-4 0 0 200 0 20 8 0. 4 120 1020 8280 5130 SSL_get_app_data2()\001
+4 0 0 200 0 20 8 0. 4 120 1020 8280 5130 ap_SSL_get_app_data2()\001
4 0 0 100 0 18 20 0. 4 270 1290 10710 7605 OpenSSL\001
4 0 0 100 0 18 12 0. 4 180 720 10710 7785 [Crypto]\001
4 0 0 100 0 18 20 0. 4 270 1290 10935 3645 OpenSSL\001
Index: modules/ssl/mod_ssl.c
===
--- modules/ssl/mod_ssl.c(revision 1673798)
+++ modules/ssl/mod_ssl.c(working copy)
@@ -570,7 +570,7 @@
}
SSL_set_app_data(ssl, c);
-SSL_set_app_data2(ssl, NULL); /* will be request_rec */
+ap_SSL_set_app_data2(ssl, NULL); /* will be request_rec */
sslconn-ssl = ssl;
Index: modules/ssl/ssl_engine_init.c
===
--- modules/ssl/ssl_engine_init.c(revision 1673798)
+++ modules/ssl/ssl_engine_init.c(working copy)
@@ -148,12 +148,12 @@
apr_status_t rv;
apr_array_header_t *pphrases;
-if (SSLeay() SSL_LIBRARY_VERSION) {
+if (SSLeay() AP_SSL_LIBRARY_VERSION) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, base_server,
APLOGNO(01882)
Init: this version of mod_ssl was compiled
against
a newer library (%s, version currently loaded
is %s)
- may result in undefined or erroneous
behavior,
- SSL_LIBRARY_TEXT, SSLeay_version(SSLEAY_VERSION));
+ AP_SSL_LIBRARY_TEXT,
SSLeay_version(SSLEAY_VERSION));
}
/* We initialize mc-pid per-process in the child init,
@@ -242,7 +242,7 @@
#endif
ap_log_error(APLOG_MARK, APLOG_INFO, 0, s, APLOGNO(01883)
- Init: Initialized %s library, SSL_LIBRARY_NAME);
+ Init: Initialized %s library, AP_SSL_LIBRARY_NAME);
/*
* Seed the Pseudo Random Number Generator (PRNG)
@@ -348,7 +348,7 @@
*/
ssl_add_version_components(p, base_server);
-SSL_init_app_data2_idx(); /* for SSL_get_app_data2() at
request time */
+ap_SSL_init_app_data2_idx(); /* for ap_SSL_get_app_data2() at
request time */
init_dh_params();
@@ -871,9 +871,9 @@
}
}
-n = SSL_CTX_use_certificate_chain(mctx-ssl_ctx,
- (char *)chain,
- skip_first, NULL);
+n = ap_SSL_CTX_use_certificate_chain(mctx-ssl_ctx,
+ (char *)chain,
+
Re: namespacing in mod_ssl
On 15.04.2015 18:36, Stefan Sperling wrote: However, the actual issue here is that mod_ssl is squatting the SSL_ namespace. Historically this may have made sense (it seems mod_ssl and OpenSSL have shared history/authors). Bill Rowe suggested to try moving mod_ssl's functions into the ap_ namespace to avoid such clashes in the future. Agreed that mod_ssl should avoid stepping into the SSL_* yard. As pointed out by Jeff, ap_* is fairly foreign in the mod_ssl case, though, and my preference is for s/SSL_/ssl_/ for functions and s/SSL_/MODSSL_/ for constants (in the latter case, there's actually quite some more stuff lurking - SSL_OPT_*, SSL_PROTOCOL_* etc.). I'm not sure how README.dsov.ps should be regenerated. It contains a refence to SSL_get_app_data2(). For now I've only updated the .dsov.fig file. With fig2dev probably. Though in this simple case, a direct edit of README.dsov.ps seems sufficient. Kaspar
Re: check for RAND_egd at configure time
On 15.04.2015 20:43, Stefan Sperling wrote: LibreSSL does not provide the RAND_egd() function. This patch adds a configure check to allow building mod_ssl with LibreSSL. Index: modules/ssl/config.m4 === --- modules/ssl/config.m4 (revision 1673798) +++ modules/ssl/config.m4 (working copy) @@ -44,6 +44,12 @@ # structure, so ask libtool to hide everything else: APR_ADDTO(MOD_SSL_LDADD, [-export-symbols-regex ssl_module]) fi + +have_rand_egd=no +AC_CHECK_LIB(crypto, RAND_egd, [have_rand_egd=yes]) +if test $have_rand_egd = yes; then +AC_DEFINE([HAVE_RAND_EGD], [1], [Define if RAND_egd exists.]) +fi else enable_ssl=no fi We already have a couple of OpenSSL function checks in (the top-level) acinclude.m4 - can you add it there? Kaspar
Re: svn commit: r1673470 - /httpd/httpd/trunk/docs/manual/mod/mod_deflate.xml
Am 15.04.2015 um 00:14 schrieb Rainer Jung:
Am 14.04.2015 um 19:06 schrieb rbo...@apache.org:
Author: rbowen
Date: Tue Apr 14 17:06:10 2015
New Revision: 1673470
URL: http://svn.apache.org/r1673470
Log:
Add pre-compressed content recipe, as per
https://bz.apache.org/bugzilla/show_bug.cgi?id=51336
Modified:
httpd/httpd/trunk/docs/manual/mod/mod_deflate.xml
Modified: httpd/httpd/trunk/docs/manual/mod/mod_deflate.xml
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_deflate.xml?rev=1673470r1=1673469r2=1673470view=diff
==
--- httpd/httpd/trunk/docs/manual/mod/mod_deflate.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_deflate.xml Tue Apr 14
17:06:10 2015
@@ -178,6 +178,51 @@ SetEnvIfNoCase Request_URI \.(?:gif|jpe?
/example
/section
+section id=precompressedtitleServing pre-compressed
+content/title
+
+pSince modulemod_deflate/module re-compresses content each
+time a request is made, some performance benefit can be derived by
+pre-compressing the content and telling mod_deflate to serve them
+without re-compressing them. This may be accomplished using a
+configuration like the following:/p
+
+highlight language=config
+ lt;IfModule mod_headers.cgt;
+# Serve gzip compressed CSS files if they exist
+# and the client accepts gzip.
+RewriteCond %{HTTP:Accept-encoding} gzip
+RewriteCond %{REQUEST_FILENAME}\.gz -s
+RewriteRule ^(.*)\.css $1\.css\.gz [QSA]
+
+# Serve gzip compressed JS files if they exist
+# and the client accepts gzip.
+RewriteCond %{HTTP:Accept-encoding} gzip
+RewriteCond %{REQUEST_FILENAME}\.gz -s
+RewriteRule ^(.*)\.js $1\.js\.gz [QSA]
+
+
+# Serve correct content types, and prevent mod_deflate double gzip.
+RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
+RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]
+
+
+lt;FilesMatch (\.js\.gz|\.css\.gz)$gt;
+ # Serve correct encoding type.
+ Header append Content-Encoding gzip
+
+ # Force proxies to cache gzipped amp;
+ # non-gzipped css/js files separately.
+ Header append Vary Accept-Encoding
+lt;/FilesMatchgt;
+ lt;/IfModulegt;
+/IfModule
+
+
+/highlight
+
+/section
+
directivesynopsis
nameDeflateFilterNote/name
descriptionPlaces the compression ratio in a note for
logging/description
AFAIK mod_rewrite automatically adds headers from RewriteCond to the
Vary header as long as no NV flag is used. So the Header append Vary
Accept-Encoding part should not be necessary.
I should probably also mention, that the recipe gets easier, once one
accepts a non-standard convention for the names of the compressed
content. If you add the .gz before the final suffix .js, .css
etc., then the web server will automatically get the content type
correct. So you can drop the T= flags. My variant of the recipe was:
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_FILENAME} ^(.+)\.(css|js)$
RewriteCond %1.gz%2 -s
RewriteRule ^(.+)\.(css|js)$ $1.gz.$2 [QSA,E=gz:1,E=no-gzip:1]
Header append Content-Encoding gzip env=gz
The additional replacement of FilesMatch with a custom env var (here
named gz) one can check in the Header append part is independent of
the other change.
One could drop the second and third RewriteCond, if one assumes that all
such files have been compressed. To create the compressed files with
non-standard name convention, one can use on Unix/Linux a script like e.g.
CONTENT_DIR=/opt/myapp/static/
PERMS=644
for suffix in css js
do
for file in \
`find $CONTENT_DIR -type f -name *.$suffix -a ! -name *.gz.*`
do
gzfile=`echo $file | sed -e 's#\.'$suffix'#.gz.'$suffix'#'`
gzip --best -c $file $gzfile
chmod $PERMS $gzfile
echo === $file $gzfile ===
ls -ld $file $gzfile
done
done
I like the idea of adding this as a feature to mod_deflate. I actually
started doing this a few weeks ago but got side-tracked.
Regards,
Rainer
Re: Extending mod_authz_dbd
On 14 Apr 2015, at 7:38 PM, Jose Kahan jose.ka...@w3.org wrote:
require sql-query SELECT * FROM foo WHERE user=${REMOTE_USER}
AND uri=${REQUEST_URI} AND ${REQUEST_METHOD} in
('GET', 'POST')
While browsing for information regarding this point, I only
found people asking if this was possible, but no hints if there
had been (or will be) plans to do this.
The defunct mod_auth_mysql used to propose something similar. i
This module is not officially maintained anymore.
A possible point of confusion in the module's doc [1] is the
phrase saying
Since v2.4.8, expressions are supported within the DBD
require directives.”
Hmmm…
The limitations we’d have to work with is that all the queries are prepared
statements, and are reused for multiple requests. At the same time any query
that is interpreted purely as a string would need to be protected against SQL
injection.
One possible way of approaching this would be to extend the dbd-login and
dbd-logout require directives with optional expression parameters, which can
then be referred to in the prepared statement, so you could do this:
Require dbd-login %{REQUEST_URI} %{REQUEST_METHOD} %{REMOTE_USER}
AuthzDBDQuery UPDATE authn SET uri = %s, method = %s WHERE user = %s”
Require dbd-logout %{TIME} %{REMOTE_USER}
AuthzDBDQuery UPDATE authn SET logout_time = %s WHERE user = %s”
To be backwards compatible, Require dbd-login” on it’s own would imply
Require dbd-login %{REMOTER_USER}”.
One possible approach to support completely generic queries might be as follows:
Require dbd-query %{REQUEST_URI} %{REMOTE_USER}
AuthzDBDQuery “SELECT count(user) FROM authn WHERE uri=%s AND user = %s”
The bit above where you’d limit the requests to GET or POST you’d probably do
with Limit or LimitExcept.
Regards,
Graham
—
