Re: ALPN patch comments
I don't know if I have any points to give here, but if NPN does not make it to 2.4, it's fine with me to remove it from trunk also. Only mod_spdy is affected afaik. //Stefan > Am 23.04.2015 um 06:56 schrieb Kaspar Brand : > >> On 22.04.2015 21:30, Rainer Jung wrote: >>> Am 22.04.2015 um 17:49 schrieb Kaspar Brand: >>> Thanks. In the patch for ssl_private.h, the complete NPN block should >>> actually be dropped - the same block is are already part of >>> ssl_private.h, just 10 lines above. >> >> I've kept the new one and dropped the old one in r1675459. > > It's nitpicking, but... the old one was already correct, actually. All > this stuff is in a larger "#if !defined(OPENSSL_NO_TLSEXT) ..." block, > so there's no need to repeat NO_TLSEXT. > > I'd rather get consensus on completely dropping HAVE_TLS_NPN from trunk > anyway, though, so it's really a very minor point right now ;-) > > Kaspar
Re: ALPN patch comments
On 22.04.2015 21:30, Rainer Jung wrote: > Am 22.04.2015 um 17:49 schrieb Kaspar Brand: >> Thanks. In the patch for ssl_private.h, the complete NPN block should >> actually be dropped - the same block is are already part of >> ssl_private.h, just 10 lines above. > > I've kept the new one and dropped the old one in r1675459. It's nitpicking, but... the old one was already correct, actually. All this stuff is in a larger "#if !defined(OPENSSL_NO_TLSEXT) ..." block, so there's no need to repeat NO_TLSEXT. I'd rather get consensus on completely dropping HAVE_TLS_NPN from trunk anyway, though, so it's really a very minor point right now ;-) Kaspar
Re: ALPN patch comments
On 22.04.2015 18:45, Stefan Eissing wrote: > I understand your argument. My pov is of someone trying to bring > http/2 to the people. While bringing a new httpd on an existing > system seems easy, installing a new system openssl is more > challenging with its dependencies and the changes in hiding non > public parts of their API. It doesn't necessarily mean replacing the system OpenSSL version. A separately built version (static libs only, which is OpenSSL's default) is fine for mod_ssl - just specify via "./configure --with-ssl=". I believe Ivan Ristic once had something on it in his blog, it's a fairly straightforward and painless option for an admin, I think. Kaspar
Re: svn commit: r1675471 - in /httpd/httpd/trunk/docs/manual/mod: core.xml mod_mime.xml
ty, helper script updated to run validate-xml On Wed, Apr 22, 2015 at 3:45 PM, Mike Rumph wrote: > Hello Eric, > > This changed gives the following error when ./build.sh validate-xml is run: > > Buildfile: build.xml > > validate-xml: > [xmlvalidate] /home/mrumph/httpd-trunk/docs/manual/mod/core.xml:1916:7: The > element type "p" must be terminated by the matching end-tag "". > > BUILD FAILED > /home/mrumph/httpd-trunk/docs/manual/style/lang-targets.xml:294: Could not > validate document /home/mrumph/httpd-trunk/docs/manual/mod/core.xml > > Thanks, > > Mike > > > On 4/22/2015 12:37 PM, cove...@apache.org wrote: >> >> Author: covener >> Date: Wed Apr 22 19:37:03 2015 >> New Revision: 1675471 >> >> URL: http://svn.apache.org/r1675471 >> Log: >> >> reword per feedback >> >> Modified: >> httpd/httpd/trunk/docs/manual/mod/core.xml >> httpd/httpd/trunk/docs/manual/mod/mod_mime.xml >> >> Modified: httpd/httpd/trunk/docs/manual/mod/core.xml >> URL: >> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/core.xml?rev=1675471&r1=1675470&r2=1675471&view=diff >> >> == >> --- httpd/httpd/trunk/docs/manual/mod/core.xml (original) >> +++ httpd/httpd/trunk/docs/manual/mod/core.xml Wed Apr 22 19:37:03 2015 >> @@ -1892,18 +1892,27 @@ ForceType image/gif >> static files, where the generator of the response typically >> specifies >> a Content-Type, this directive has no effect. >> + >> Note >> +If no handler is explicitly set for a request, the specified >> content >> +type will also be used as the handler name. >> + >> When explicit directives such as >> SetHandler or >> AddHandler do not apply >> to the current request, the internal handler name normally set by >> those >> -directives is set to match the content type specified by this >> directive. >> +directives is instead set to the content type specified by this >> directive. >> + >> This is a historical behavior that some third-party modules >> -(such as mod_php) may use "magic" content types used only to signal >> the >> -module to take responsibility for the matching request. >> Configurations >> -that rely on such "magic" types should be avoided by the use of >> +(such as mod_php) may look for a "synthetic" content type used only >> to >> +signal the module to take responsibility for the matching request. >> + >> + >> +Configurations that rely on such "synthetic" types should be >> avoided. >> +Additionally, configurations that restrict access to >> SetHandler or >> -AddHandler. >> +AddHandler should >> +restrict access to this directive as well. >> >> >> >> Modified: httpd/httpd/trunk/docs/manual/mod/mod_mime.xml >> URL: >> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_mime.xml?rev=1675471&r1=1675470&r2=1675471&view=diff >> >> == >> --- httpd/httpd/trunk/docs/manual/mod/mod_mime.xml (original) >> +++ httpd/httpd/trunk/docs/manual/mod/mod_mime.xml Wed Apr 22 19:37:03 >> 2015 >> @@ -610,17 +610,25 @@ AddType application/rss+xml;qs=0.8 .xml >> Note >> +If no handler is explicitly set for a request, the specified >> content >> +type will also be used as the handler name. >> + >> When explicit directives such as >> SetHandler or >> AddHandler do not apply >> to the current request, the internal handler name normally set by >> those >> -directives is set to match the content type specified by this >> directive. >> +directives is instead set to the content type specified by this >> directive. >> + >> This is a historical behavior that some third-party modules >> -(such as mod_php) may use "magic" content types used only to signal >> the >> -module to take responsibility for the matching request. >> Configurations >> -that rely on such "magic" types should be avoided by the use of >> +(such as mod_php) may look for a "synthetic" content type used only >> to >> +signal the module to take responsibility for the matching request. >> + >> + >> +Configurations that rely on such "synthetic" types should be >> avoided. >> +Additionally, configurations that restrict access to >> SetHandler or >> -AddHandler. >> +AddHandler should >> +restrict access to this directive as well. >> >> >> >> >> >> > -- Eric Covener cove...@gmail.com
Re: svn commit: r1675471 - in /httpd/httpd/trunk/docs/manual/mod: core.xml mod_mime.xml
Hello Eric, This changed gives the following error when ./build.sh validate-xml is run: Buildfile: build.xml validate-xml: [xmlvalidate] /home/mrumph/httpd-trunk/docs/manual/mod/core.xml:1916:7: The element type "p" must be terminated by the matching end-tag "". BUILD FAILED /home/mrumph/httpd-trunk/docs/manual/style/lang-targets.xml:294: Could not validate document /home/mrumph/httpd-trunk/docs/manual/mod/core.xml Thanks, Mike On 4/22/2015 12:37 PM, cove...@apache.org wrote: Author: covener Date: Wed Apr 22 19:37:03 2015 New Revision: 1675471 URL: http://svn.apache.org/r1675471 Log: reword per feedback Modified: httpd/httpd/trunk/docs/manual/mod/core.xml httpd/httpd/trunk/docs/manual/mod/mod_mime.xml Modified: httpd/httpd/trunk/docs/manual/mod/core.xml URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/core.xml?rev=1675471&r1=1675470&r2=1675471&view=diff == --- httpd/httpd/trunk/docs/manual/mod/core.xml (original) +++ httpd/httpd/trunk/docs/manual/mod/core.xml Wed Apr 22 19:37:03 2015 @@ -1892,18 +1892,27 @@ ForceType image/gif static files, where the generator of the response typically specifies a Content-Type, this directive has no effect. + Note +If no handler is explicitly set for a request, the specified content +type will also be used as the handler name. + When explicit directives such as SetHandler or AddHandler do not apply to the current request, the internal handler name normally set by those -directives is set to match the content type specified by this directive. +directives is instead set to the content type specified by this directive. + This is a historical behavior that some third-party modules -(such as mod_php) may use "magic" content types used only to signal the -module to take responsibility for the matching request. Configurations -that rely on such "magic" types should be avoided by the use of +(such as mod_php) may look for a "synthetic" content type used only to +signal the module to take responsibility for the matching request. + + +Configurations that rely on such "synthetic" types should be avoided. +Additionally, configurations that restrict access to SetHandler or -AddHandler. +AddHandler should +restrict access to this directive as well. Modified: httpd/httpd/trunk/docs/manual/mod/mod_mime.xml URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_mime.xml?rev=1675471&r1=1675470&r2=1675471&view=diff == --- httpd/httpd/trunk/docs/manual/mod/mod_mime.xml (original) +++ httpd/httpd/trunk/docs/manual/mod/mod_mime.xml Wed Apr 22 19:37:03 2015 @@ -610,17 +610,25 @@ AddType application/rss+xml;qs=0.8 .xml Note +If no handler is explicitly set for a request, the specified content +type will also be used as the handler name. + When explicit directives such as SetHandler or AddHandler do not apply to the current request, the internal handler name normally set by those -directives is set to match the content type specified by this directive. +directives is instead set to the content type specified by this directive. + This is a historical behavior that some third-party modules -(such as mod_php) may use "magic" content types used only to signal the -module to take responsibility for the matching request. Configurations -that rely on such "magic" types should be avoided by the use of +(such as mod_php) may look for a "synthetic" content type used only to +signal the module to take responsibility for the matching request. + + +Configurations that rely on such "synthetic" types should be avoided. +Additionally, configurations that restrict access to SetHandler or -AddHandler. +AddHandler should +restrict access to this directive as well.
Re: ALPN patch comments
Am 22.04.2015 um 17:49 schrieb Kaspar Brand: On 22.04.2015 10:52, Stefan Eissing wrote: I made two small patches based on the feedback from Kaspar. One for the code and one for the documentation. Thanks. In the patch for ssl_private.h, the complete NPN block should actually be dropped - the same block is are already part of ssl_private.h, just 10 lines above. I've kept the new one and dropped the old one in r1675459. The condition was slightly different. I dropped #if !defined(OPENSSL_NO_NEXTPROTONEG) && defined(OPENSSL_NPN_NEGOTIATED) and kept #if !defined(OPENSSL_NO_NEXTPROTONEG) && !defined(OPENSSL_NO_TLSEXT) && defined(OPENSSL_NPN_NEGOTIATED) Hope that's OK. Regards, Rainer
Re: svn commit: r1675436 - /httpd/httpd/trunk/docs/manual/mod/mod_authnz_ldap.xml
Hello Eric, This change gives the following error when ./build.sh validate-xml is run: Buildfile: build.xml validate-xml: [xmlvalidate] /home/mrumph/httpd-trunk/docs/manual/mod/mod_authnz_ldap.xml:114:49: Attribute "name" must be declared for element type "module". [xmlvalidate] /home/mrumph/httpd-trunk/docs/manual/mod/mod_authnz_ldap.xml:118:28: Attribute "name" must be declared for element type "module". BUILD FAILED /home/mrumph/httpd-trunk/docs/manual/style/lang-targets.xml:294: /home/mrumph/httpd-trunk/docs/manual/mod/mod_authnz_ldap.xml is not a valid XML document. Thanks, Mike Rumph On 4/22/2015 10:44 AM, cove...@apache.org wrote: Author: covener Date: Wed Apr 22 17:44:00 2015 New Revision: 1675436 URL: http://svn.apache.org/r1675436 Log: add a prominent caveat about the effect of caching. PR55089 Modified: httpd/httpd/trunk/docs/manual/mod/mod_authnz_ldap.xml Modified: httpd/httpd/trunk/docs/manual/mod/mod_authnz_ldap.xml URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_authnz_ldap.xml?rev=1675436&r1=1675435&r2=1675436&view=diff == --- httpd/httpd/trunk/docs/manual/mod/mod_authnz_ldap.xml (original) +++ httpd/httpd/trunk/docs/manual/mod/mod_authnz_ldap.xml Wed Apr 22 17:44:00 2015 @@ -67,8 +67,8 @@ for HTTP Basic authentication.Contents - -Operation + General caveats + Operation The Authentication @@ -109,6 +109,16 @@ for HTTP Basic authentication. +General caveats + This module caches authentication and authorization results based +on the configuration of mod_ldap. Changes +made to the backing LDAP server will not be immediately reflected on the +HTTP Server, including but not limited to user lockouts/revocations, +password changes, or changes to group memberships. Consult the directives +in mod_ldap for details of the cache tunables. + + + Operation There are two phases in granting access to a user. The first
Re: ALPN patch comments
> > For me the time seems right to rip NPN out of trunk and only backport > the ALPN code to 2.4. > I'd be +1 for that.
Re: ALPN patch comments
> Am 22.04.2015 um 17:49 schrieb Kaspar Brand : > >> On 22.04.2015 10:52, Stefan Eissing wrote: >> I made two small patches based on the feedback from Kaspar. One for >> the code and one for the documentation. > > Thanks. In the patch for ssl_private.h, the complete NPN block should > actually be dropped - the same block is are already part of > ssl_private.h, just 10 lines above Yes. Not my change though. ;-) >> However there are a lot of openssl 1.0.1 installations out there >> where httpd 2.4 is deployed which already talk NPN > > "a lot of... which already talk NPN"? I have a bit a hard time in > following this argument: since mod_ssl in 2.4 doesn't have NPN, this > suggests that these installations currently rely on custom patches in > any case - so I wouldn't expect there to be "a lot of" (or I might be > missing the real point) The openssl 1.0.1 which is out there talks NPN. That's what I meant. I understand your argument. My pov is of someone trying to bring http/2 to the people. While bringing a new httpd on an existing system seems easy, installing a new system openssl is more challenging with its dependencies and the changes in hiding non public parts of their API. My original patch was replacing the mod_ssl NPN registration with the ALPN ones, but using the NPN internally when linking against an openssl without ALPN. It was not completely hidden since both work slightly different, though. Just my €0.02. I will be happy if "just" the ALPN parts make their way into the next 2.4. //stefan >> and it might take some time for getting ALPN support from the >> distros. Which would mean more people building and deploying their >> own SSL libraries/patching mod_ssl and having no auto update, if they >> want to use SPDY or HTTP/2. > > I don't find this reasoning very convincing... if we look at > distributions with long term support (which is the sort of thing to > consider for running a production HTTP server), then we see that they > are now at 2.4.6 (RHEL), 2.4.7 (Ubuntu), 2.4.10 (SLES) or similar. And > they usually stay with these versions for the whole OS release lifetime, > only security fixes are backported (new features only in exceptional > cases). I.e., it's highly unlikely that admins could rely on the > vendor-supplied httpd package to get NPN in the next, say, 12 months. > "auto update" typically means "security fixes only". > > OTOH, if a distributor is really going from 2.4.x to 2.4-latest this or > next year, then I'd say that chances are quite high that he also > upgrades to OpenSSL 1.0.2 at the same time (in particular given the > increased pace for new OpenSSL releases and the faster EOL timelines, > see https://www.openssl.org/about/releasestrat.html). > > For me the time seems right to rip NPN out of trunk and only backport > the ALPN code to 2.4. > > Kaspar
Re: ALPN patch comments
On 22.04.2015 10:52, Stefan Eissing wrote: > I made two small patches based on the feedback from Kaspar. One for > the code and one for the documentation. Thanks. In the patch for ssl_private.h, the complete NPN block should actually be dropped - the same block is are already part of ssl_private.h, just 10 lines above. > However there are a lot of openssl 1.0.1 installations out there > where httpd 2.4 is deployed which already talk NPN "a lot of... which already talk NPN"? I have a bit a hard time in following this argument: since mod_ssl in 2.4 doesn't have NPN, this suggests that these installations currently rely on custom patches in any case - so I wouldn't expect there to be "a lot of" (or I might be missing the real point). > and it might take some time for getting ALPN support from the > distros. Which would mean more people building and deploying their > own SSL libraries/patching mod_ssl and having no auto update, if they > want to use SPDY or HTTP/2. I don't find this reasoning very convincing... if we look at distributions with long term support (which is the sort of thing to consider for running a production HTTP server), then we see that they are now at 2.4.6 (RHEL), 2.4.7 (Ubuntu), 2.4.10 (SLES) or similar. And they usually stay with these versions for the whole OS release lifetime, only security fixes are backported (new features only in exceptional cases). I.e., it's highly unlikely that admins could rely on the vendor-supplied httpd package to get NPN in the next, say, 12 months. "auto update" typically means "security fixes only". OTOH, if a distributor is really going from 2.4.x to 2.4-latest this or next year, then I'd say that chances are quite high that he also upgrades to OpenSSL 1.0.2 at the same time (in particular given the increased pace for new OpenSSL releases and the faster EOL timelines, see https://www.openssl.org/about/releasestrat.html). For me the time seems right to rip NPN out of trunk and only backport the ALPN code to 2.4. Kaspar
Re: SSLDisableCRLCaching, is it even possible in 2.4.x?
On 22.04.2015 10:36, Jan Kaluža wrote: > On 04/22/2015 09:50 AM, Kaspar Brand wrote: >> Fiddling with OpenSSL internals >> looks rather scary to me, at least at first sight - perhaps there's an >> API for clearing a CRL store in OpenSSL? > > Unfortunately there's no such API in OpenSSL. There's "caching" flag in > X509_STORE struct, but it's never used for anything actually. > > Maybe it would be better idea to implement that in OpenSSL +1 for this, indeed. It would be good to not repeat history - i.e., add code to mod_ssl which actually belongs into OpenSSL (specifically in this case, where we would operate on low-level OpenSSL structures, which looks like a fairly brittle approach). > I was hoping to have this feature in httpd at first. Understandable from an httpd package maintainer's point of view, I agree. Could a temporary patch to your vendor OpenSSL package be a short-term approach, with the long-term goal of getting it added as an offical API into OpenSSL 1.0.something? Kaspar
Re: svn commit: r1674542 - in /httpd/httpd/trunk: acinclude.m4 modules/ssl/ssl_engine_rand.c
On 22.04.2015 10:12, Stefan Sperling wrote: > On Wed, Apr 22, 2015 at 09:29:49AM +0200, Kaspar Brand wrote: >> Sorry for having missed this in my previous review: we should also >> #ifdef the SSL_RSSRC_EGD case in >> ssl_engine_config.c:ssl_cmd_SSLRandomSeed(), to make sure that "egd:..." >> settings are not silently ignored when mod_ssl is compiled against >> LibreSSL. Either let the failure then be detected by the >> ssl_util_path_check, or (probably better) reject it similar to how it's >> done for SSLCompression, SSLHonorCipherOrder etc. >> >> Kaspar > > Thanks, good catch. > > Is this fine? Looks good to me, yes - thanks. Kaspar
Apache (httpd) Wiki
There is an error on this page which is "immutable" and cannot be edited by an ordinary user (even logged in): https://wiki.apache.org/httpd/FileSystemPermissions The error is in this the last line: What we've done here is to set all files to 640, or rw-r--r-- and directories to rwxr-x---. Because the group "web-content" is applied to all the files and directories, httpd can read these files, but cannot write to them. The error phrase is here: "set all files to 640, or rw-r--r--" which should read: "set all files to 640, or rw-r-" Best regards, -Tom
ALPN patch comments
I made two small patches based on the feedback from Kaspar. One for the code and one for the documentation. Since I build against releases, I did not test the doc patch building. This code patch I tested against my already patched 2.4.12 with openssl 1.0.2 and 1.0.1 in mod_h2 sandbox. Re NPN support comments: I can sympathize with only bringing „official“ protocols into a release branch (2.4). However there are a lot of openssl 1.0.1 installations out there where httpd 2.4 is deployed which already talk NPN and it might take some time for getting ALPN support from the distros. Which would mean more people building and deploying their own SSL libraries/patching mod_ssl and having no auto update, if they want to use SPDY or HTTP/2. Does not seem like an easy decision. Cheers, Stefan alpn-doc.patch Description: Binary data alpn-trunk-2.unified.diff.patch Description: Binary data bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: SSLDisableCRLCaching, is it even possible in 2.4.x?
On 04/22/2015 09:50 AM, Kaspar Brand wrote: On 21.04.2015 12:20, Jan Kaluža wrote: we used to have a patch against httpd-2.2.15 to add SSLDisableCRLCaching option to not cache CRLs. I was trying to adapt this patch for httpd-trunk and eventually include it upstream but now I'm in dead end. The patch removes all the CRLs from the per-server_rec OpenSSL cache created in ssl_init_ctx_crl (OpenSSL caches the CRLs in X509_store.objs). This all works properly, but I'm thinking about thread-safety. Starting with 2.3.15 (https://svn.apache.org/r1165056), CRL checking was completely delegated to OpenSSL, so it would be a bit surprising to me if that patch can be ported to trunk. I'm aware of that, that's why I'm rewriting that patch for trunk :). Fiddling with OpenSSL internals looks rather scary to me, at least at first sight - perhaps there's an API for clearing a CRL store in OpenSSL? Unfortunately there's no such API in OpenSSL. There's "caching" flag in X509_STORE struct, but it's never used for anything actually. Maybe it would be better idea to implement that in OpenSSL, but that's kind of long-term goal. I was hoping to have this feature in httpd at first. Kaspar Regards, Jan Kaluza
Re: svn commit: r1674542 - in /httpd/httpd/trunk: acinclude.m4 modules/ssl/ssl_engine_rand.c
On Wed, Apr 22, 2015 at 09:29:49AM +0200, Kaspar Brand wrote:
> Sorry for having missed this in my previous review: we should also
> #ifdef the SSL_RSSRC_EGD case in
> ssl_engine_config.c:ssl_cmd_SSLRandomSeed(), to make sure that "egd:..."
> settings are not silently ignored when mod_ssl is compiled against
> LibreSSL. Either let the failure then be detected by the
> ssl_util_path_check, or (probably better) reject it similar to how it's
> done for SSLCompression, SSLHonorCipherOrder etc.
>
> Kaspar
Thanks, good catch.
Is this fine?
Index: modules/ssl/ssl_engine_config.c
===
--- modules/ssl/ssl_engine_config.c (revision 1675266)
+++ modules/ssl/ssl_engine_config.c (working copy)
@@ -574,8 +574,15 @@ const char *ssl_cmd_SSLRandomSeed(cmd_parms *cmd,
seed->cpPath = ap_server_root_relative(mc->pPool, arg2+5);
}
else if ((arg2len > 4) && strEQn(arg2, "egd:", 4)) {
+#ifdef HAVE_RAND_EGD
seed->nSrc = SSL_RSSRC_EGD;
seed->cpPath = ap_server_root_relative(mc->pPool, arg2+4);
+#else
+return apr_pstrcat(cmd->pool, "Invalid SSLRandomSeed entropy source `",
+ arg2, "': This version of " MODSSL_LIBRARY_NAME
+ " does not support the Entropy Gathering Daemon "
+ "(EGD).", NULL);
+#endif
}
else if (strcEQ(arg2, "builtin")) {
seed->nSrc = SSL_RSSRC_BUILTIN;
Re: SSLDisableCRLCaching, is it even possible in 2.4.x?
On 21.04.2015 12:20, Jan Kaluža wrote: > we used to have a patch against httpd-2.2.15 to add SSLDisableCRLCaching > option to not cache CRLs. I was trying to adapt this patch for > httpd-trunk and eventually include it upstream but now I'm in dead end. > > The patch removes all the CRLs from the per-server_rec OpenSSL cache > created in ssl_init_ctx_crl (OpenSSL caches the CRLs in > X509_store.objs). This all works properly, but I'm thinking about > thread-safety. Starting with 2.3.15 (https://svn.apache.org/r1165056), CRL checking was completely delegated to OpenSSL, so it would be a bit surprising to me if that patch can be ported to trunk. Fiddling with OpenSSL internals looks rather scary to me, at least at first sight - perhaps there's an API for clearing a CRL store in OpenSSL? Kaspar
Re: svn commit: r1674542 - in /httpd/httpd/trunk: acinclude.m4 modules/ssl/ssl_engine_rand.c
On 18.04.2015 19:03, s...@apache.org wrote: > Author: stsp > Date: Sat Apr 18 17:03:47 2015 > New Revision: 1674542 > > URL: http://svn.apache.org/r1674542 > Log: > mod_ssl: Check for RAND_egd() at configure time and only use it if present. > Fixes the build with LibreSSL which does not provide this function. > > Modified: > httpd/httpd/trunk/acinclude.m4 > httpd/httpd/trunk/modules/ssl/ssl_engine_rand.c Sorry for having missed this in my previous review: we should also #ifdef the SSL_RSSRC_EGD case in ssl_engine_config.c:ssl_cmd_SSLRandomSeed(), to make sure that "egd:..." settings are not silently ignored when mod_ssl is compiled against LibreSSL. Either let the failure then be detected by the ssl_util_path_check, or (probably better) reject it similar to how it's done for SSLCompression, SSLHonorCipherOrder etc. Kaspar
