"An updated patch to fix a renegotiation vulnerability in SSL protocol in 0.1.0-0.8.22. The patch is not required for versions 0.8.23+ and 0.7.64+." Please bump or provide an patched ebuild.
Sorry for bugspam.
Created attachment 211024 [details, diff] patch for 0.7.64 ebuild This is a small change for 0.7.64 that enables the realip module by default, not depending on the fastcgi use flag. This module is useful for any configuration that needs to read the realip from X-Real-IP or X-Forwarded-For headers (i.e. Varnish->Nginx).
According to nginx' author, "--with-md5=/usr/include" and "--with-sha1=/usr/include" must be removed from args or changed to point to the source code of the libs that implement md5 and sha1.
What's the reason for delaying the ebuild so long? 0.7.64 is a stable release that contains a security fix, and it should be treated accordingly.
I've put 0.7.64 and 0.8.29 in the unstable trees.
Arches, please test and mark stable: =www-servers/nginx-0.7.64 =www-servers/nginx-0.8.29 Target keywords : "amd64 x86"
(In reply to comment #5) > I've put 0.7.64 and 0.8.29 in the unstable trees. No regression, but have a look at bug 241756. By the way, I will only mark the 0.7* series stable for x86, if you disagree cry now or readd us.
And it fails without USE=ssl In file included from src/http/ngx_http_file_cache.c:10: src/core/ngx_md5.h:18:17: error: md5.h: No such file or directory In file included from src/http/ngx_http_file_cache.c:10: src/core/ngx_md5.h:22: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ngx_md5_t’ src/http/ngx_http_file_cache.c: In function ‘ngx_http_file_cache_create_key’: src/http/ngx_http_file_cache.c:144: error: ‘ngx_md5_t’ undeclared (first use in this function) src/http/ngx_http_file_cache.c:144: error: (Each undeclared identifier is reported only once src/http/ngx_http_file_cache.c:144: error: for each function it appears in.) src/http/ngx_http_file_cache.c:144: error: expected ‘;’ before ‘md5’ src/http/ngx_http_file_cache.c:152: error: ‘md5’ undeclared (first use in this function) make[1]: *** [objs/src/http/ngx_http_file_cache.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory `/var/tmp/portage/www-servers/nginx-0.7.64/work/nginx-0.7.64' make: *** [build] Error 2
Firstly, I think openssl should be declared as a mandatory dep, because its md5 implementation is required, irrespective of the intended role of the ssl USE flag. Secondly, the reason it breaks appears to be due to the use of --with-md5-asm and --with-sha1-asm, as already alluded to by Pavel in Comment 3. To quote Igor Sysoev himself: "You do not need --with-openssl=/usr/lib --with-md5=/usr/lib. They are required only if you want to build OpenSSL or libmd5 from sources, but not if you want to use already built libraries. In the later case nginx will find them by itself, or if they are in non-standard place, you should help it by: --with-cc-opt="-I /path/to/headers --with-ld-opt="-L /path/to/libraries" Source: http://nginx.org/pipermail/nginx/2009-April/011066.html I removed the aformentioned configure options and tried a build with USE="-ssl" and found that it was able to compile successfully with md5 support in working order: ------------------------------------------------- checking for OpenSSL md5 crypto library ... found ... Configuration summary + OpenSSL library is not used + md5: using system crypto library ------------------------------------------------- As a side note, sha1 support wasn't detected but I don't believe it matters. I checked the sources and nothing yet uses it, whereas the md5 routines are used in "ngx_http_file_cache.c" and "ngx_http_secure_link_module.c". Igor has spoken in the past of using sha1 in a mysql module but it is nowhere to be seen (see http://permalink.gmane.org/gmane.comp.web.nginx.english/305).
Created attachment 214621 [details, diff] Fixes compile failure where USE="-ssl" This patch applies against the existing 0.7.64 ebuild.
Apologies for posting again, but I feel that it is important that I correct myself. Where I wrote "... reason it breaks appears to be due to the use of --with-md5-asm and --with-sha1-asm", I had actually intended to write: "... reason it breaks appears to be due to the use of --with-md5 and --with-sha1".
In http://n2.nabble.com/Dependencies-td3865386.html, Igor writes "nginx can be built without any external library. nginx may use zlib (gzip), PCRE (regexes), and md5 (cache), however, you disable these features. Also, nginx may use OpenSSL, libxslt, libperl, libGD, GeoIP, and Google perftools." so I don't see why we should require the OpenSSL dependency? Also, why does our package depend on perl unconditionally? That seems wrong.
This is a security bug, reopen.
Re Comment 12, surely it should be obvious. You need MD5 support unless you have a plan to start building nginx with "--without-http-cache". I pointed out before that its required in ngx_http_file_cache.c and that's why Igor says "may use ... md5 (cache)" (emphasis on may). If you don't want to use md5, the cache has to go and presumably that's not on the agenda. Have actually looked at the build error that Christain is complaining about? In file included from src/http/ngx_http_file_cache.c:10: src/core/ngx_md5.h:18:17: error: md5.h: No such file or directory In file included from src/http/ngx_http_file_cache.c:10: src/core/ngx_md5.h:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ngx_md5_t' src/http/ngx_http_file_cache.c: In function 'ngx_http_file_cache_create_key': src/http/ngx_http_file_cache.c:129: error: 'ngx_md5_t' undeclared (first use in this function) src/http/ngx_http_file_cache.c:129: error: (Each undeclared identifier is reported only once src/http/ngx_http_file_cache.c:129: error: for each function it appears in.) src/http/ngx_http_file_cache.c:129: error: expected ';' before 'md5' src/http/ngx_http_file_cache.c:137: error: 'md5' undeclared (first use in this function) make[1]: *** [objs/src/http/ngx_http_file_cache.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory `/var/tmp/portage/www-servers/nginx-0.7.62/work/nginx-0.7.62' make: *** [build] Error 2 As I said also, it's require by "ngx_http_secure_link_module.c" but, as far as I can tell, that isn't enabled by default - not unless "--with-http_secure_link_module" is passed to ./configure. So I maintain that openssl should indeed be a fixed dep, unless you intend to expose more configure choices to the end-user, or unless you intend to start turning off these features mandatorily. Just to get back to the original point as well, --with-md5 should not be invoked with a directory as a parameter, unless that directory contains sources (which it does not). As already demonstrated, it need not be invoked at all and sha1 support isn't actually used in the nginx codebase (yet).
Also, regarding perl, I really don't know why it's in the ebuild as a fixed dep. Maybe it's a mistake, or maybe nginx fails to build without it regardless of whether --with-http_perl_module is used or not?
Examples from the NetBSD and FreeBSD ports re-inforcing Igor's remarks that --with-cc-opt and --with-ld-opt are the appropriate options to use if there is a wish to explicitly reference required external headers (including those of OpenSSL): NetBSD: CONFIGURE_ARGS+= --with-ld-opt=-L${PREFIX}/lib\ -Wl,-R${PREFIX}/lib FreeBSD: CONFIGURE_ARGS+=--prefix=${ETCDIR} \ --with-cc-opt="-I ${LOCALBASE}/include" \ --with-ld-opt="-L ${LOCALBASE}/lib" \ Neither of them use *any* of the following: --with-pcre, --with-md5, --with-sha1, --with-zlib, --with-openssl (i.e. all the options which are designed to be invoked so that they point to a directory containing the *sources* of the relevant library). I suppose the most correct thing to do might be to invoke --with-cc-opt and --with-ld-opt to refer to "${ROOT}/lib" in the case of Gentoo but, if not otherwise instructed, the build system will look for headers under /usr/lib and find them.
Correction: refer to "${ROOT}/include" and "${ROOT}/lib" respectively, and the headers would be found under /usr/include of course. Anyway, I'll stop spamming - I've said all that needs to be said.
Thanks for your elaborate investigation! Sorry if I'm being dense, I'm just trying to figure this out before I commit something stupid. So: - the basic server doesn't need ssl - the cache module needs an md5 routine - gentoo always includes the cache module - the md5 routine is grabbed from openssl in gentoo Correct? So I'm unsure about this: "md5: using system crypto library" It would appear to me that the system crypto library is something other than openssl. You quote Igor as stating "nginx may use zlib (gzip), PCRE (regexes), and md5 (cache), however, you disable these features. Also, nginx may use OpenSSL, libxslt, libperl, libGD, GeoIP, and Google perftools", which seems to imply that md5 != openssl, so that's what lead me to wonder if we do need openssl. Also, why did you remove the --with-*-asm flags? I'm not seeing any need for this based on any of your comments, I think. (Thanks again for answering my questions.)
Re: Comment 18 ... >>> - the basic server doesn't need ssl Correct. >>> - the cache module needs an md5 routine Yes, and the secure link module. Otherwise you will encounter the following error: ./configure: error: the HTTP cache module requires md5 functions from OpenSSL library. You can either disable the module by using --without-http-cache option, or install the OpenSSL library into the system, or build the OpenSSL library statically from the source with nginx by using --with-http_ssl_module --with-openssl=<path> options. >>> - gentoo always includes the cache module Yes. You can determine this based on two things: 1) if you run ./configure --help | grep http-cache within the nginx sources the only option to be seen is --without-http-cache (indicating that it is compiled in by default) 2) the ebuild is not specifying --without-http-cache ;) Using the same method, you can determine that http_secure_link_module is not built in by default. >>> - the md5 routine is grabbed from openssl in gentoo Yes, but not just in gentoo. nginx expects to use openssl to that end in any situation. It's stated plainly by the error message I reproduced above. And there is the option of passing compiler/linker options to ensure that it is found. >>> It would appear to me that the system crypto library is something >>> other than openssl. No, it's definitely openssl. Aside from what has already been discussed, try renaming /usr/include/openssl to something else then running ./configure. It will fail ... unless you pass --without-http-cache. As for the other dependencies, it obviously boils down to how we choose to configure nginx and/or how we let the user control that process. As far as I can tell, most of these relationships can be determined simply by studying the configure --help text alone. >>> Also, why did you remove the --with-*-asm flags? I'm not seeing any >>> need for this based on any of your comments, I think. (Thanks again >>> for answering my questions.) That's a good question. The fact is I hadn't made a conscious decision to remove them and as I started to write this sentence, I realised that I had no idea as to the actual ramfications! So, one brief investigation later, I think I now understand. When compiling OpenSSL itself, the MD5_ASM and/or SHA1_ASM environment variables may be defined so as to use some x86 optimised assembler routines. Interestingly, the routines in questions are encapsulated in perl (see "crypto/md5/asm/md5-586.pl" and "crypto/md5/asm/md5-x86_64.pl" in the OpenSSL sources). Further, it can be seen in nginx's "auto/lib/md5/make" file that it will define MD5_ASM if building the OpenSSL sources (the relation to --with-md5-asm can be seen in the "auto/options"). So, my tentative conclusion is as follows: if --with-md5-asm is defined AND if nginx is instructed to build openssl itself by way of pointing it to a valid source tree using --with-md5 (*), it will add -DMD5-ASM to CFLAGS when building OpenSSL. But we don't want to do that, do we? We just want to link in the openssl library that's already provided by the distro, just like the BSDs are doing. If openssl is to be optimised in any way, that should be a matter for the openssl ebuild itself. Therefore, I think my original patch is actually right. Specifying --with-md5-asm should be superfluous if we are linking in the system-provided library, as nginx is not taking any responsibility for building any OpenSSL code (nor does it even have access to the sources). For safety's sake, we should probably drop the two lines as per the patch, but instead add the following as per Igor's comment and the BSDs: --with-cc-opt="-I${ROOT}/include" \ --with-ld-opt="-L${ROOT}/lib" I'm guessing that will help portage do the right thing under unusual conditions - are there any conditions where $ROOT would not "/"? Anyway, I'll leave that question to you developers. In my testing, it works with or without. --- (*) The very configure option which we are currently misusing and which is leading to the compile failure under discussion. The correct way to use it would be --with-md5=/path/to/openssl/sources.
My apologies. When discussing the compiler/linker options, I should have wrote: --with-cc-opt="-I${ROOT}/usr/include" \ --with-ld-opt="-L${ROOT}/usr/lib" Just for kicks, I added these and tried passing deliberately incorrect paths to see if it would affect the build. Turns out that it doesn't, so unless there are any legitimate circumstances under which ${ROOT} would not be "/" and where we wouldn't be able to include openssl from the normal paths, I suppose we needn't bother.
Committed new revisions of 0.7.64 and 0.8.29. Kerin, would you be interested in becoming a gentoo dev, by any means?
stable x86
Christian: I don't think we want to have a stable 0.8.x yet. Upstream has considered 0.8.x unstable so far, and we haven't previously had a stable 0.8 yet, as far as I can see.
Re: Comment 23 - Indeed. Why, even Arch Linux are sticking to 0.7.64, a distro whose motto appears to be "if upstream so much as twitches, pounce with all the ferocity of a rabid leopard!" Re: Comment 21 - Thanks, but I don't think I could consistently cope with the duties/responsibilities (i.e. work) that would be entailed, and I don't identify with the culture anymore to the extent that I would have any notion as to where I would fit in. I just (contribute to|complain about) things that I use or am interested in from time to time, energy permitting, and don't encounter any impedance that can be attributed alone to my not being among the developer cognoscenti, most of the time. That's also a very subtle way of saying that the things I would like to change are not things that I think I could possibly change anyway. I'm going to be a cheeky monkey now and ask amd64 to hurry along with the stabilisation for 0.7.64 ... thanks!
amd64 stable, all arches done.
I think this can be closed now.
No it can't. Please see: http://www.gentoo.org/security/en/vulnerability-policy.xml Ready to vote, I vote YES (together with the other nginx stuff).
YES too, added to request.
glsa anyone?
This issue was resolved and addressed in GLSA 201203-22 at http://security.gentoo.org/glsa/glsa-201203-22.xml by GLSA coordinator Sean Amoss (ackle).
