Re: apache2 wheezy backport
Hi, On 21.09.2013 23:27, Stefan Fritsch wrote: That would be a rather large piece of work. It would be incompatible with basically all apache modules and web-app packages in wheezy, so those would need backporting, too. Considering that there is still plenty of work to do in jessie, I don't think a backport will happen anytime soon. I do not think this will _ever_ happen. An Apache 2.4 backport would trigger a massive chain of reverse dependencies which need a backport, too (we talk about 250+ packages here). This is a massive change of Wheezy which is not conforming to backport policies. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
apache2 wheezy backport
Hi apache maintainers, Could you provide a backport of jessie apache2 to wheezy-backports? I would like some of the newer SSL features. Someone pointed out this HOWTO https://tinyurl.com/nl8965g that is recommending people frankenstein their systems by installing jessie libc6 in order to install jessie apache2 on wheezy. I think a backport would be a much cleaner way of solving that. (there may be some additional things in that HOWTO that would be good to consider for the apache2 packages, I haven't reviewed it closely to see if it's good advice) If this is just a matter of rebuilding things for wheezy-backports and uploading and you'd like me to do that, just let know. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130921204835.5eea3...@taggart.lackof.org
Re: apache2 wheezy backport
Hi Matt, Am Samstag, 21. September 2013, 13:48:35 schrieb Matt Taggart: Could you provide a backport of jessie apache2 to wheezy-backports? That would be a rather large piece of work. It would be incompatible with basically all apache modules and web-app packages in wheezy, so those would need backporting, too. Considering that there is still plenty of work to do in jessie, I don't think a backport will happen anytime soon. I would like some of the newer SSL features. If you are only looking for ECC/ECDHE, you could try this patch http://people.apache.org/~sf/ECC-2.2-v2.diff on the wheezy package. I think we may include it in a future wheezy point release, but I would like it to be aproved for upstream 2.2.x, first. Someone pointed out this HOWTO https://tinyurl.com/nl8965g that is recommending people frankenstein their systems by installing jessie libc6 in order to install jessie apache2 on wheezy. I think a backport would be a much cleaner way of solving that. Updating to jessie seems like the only sane solution right now. Cheers, Stefan -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1933183.ZaSZLq5pCG@k
Re: apache2 wheezy backport
Hi, If you are only looking for ECC/ECDHE, you could try this patch http://people.apache.org/~sf/ECC-2.2-v2.diff on the wheezy package. I think we may include it in a future wheezy point release, but I would like it to be aproved for upstream 2.2.x, first. I got pointed to this particular thread. The patchfile you mentioned seems okay, save for two issues. First, the patch still has hardcoded 1024-bit DH parameters. While offering forward secrecy, using 1k DH makes for a weaker key exchange than using 4096-bit RSA. Personally, I'd actually argue against using ephemeral DH exchanges with 1024 bit DH params in favour of 4k RSA exchanges. But I am rather paranoid about this. More importantly, the patch still uses NID_X9_62_prime256v1 which in turn uses Dual_EC_DRBG as its pseudo-RNG. This is problematic, as there have long been suspicions about this PRNG being not so random which have recently surfaced again: https://tinyurl.com/omsx9v6 More importantly, the NIST now actively discourages use of Dual_EC_DRBG in 800-90A: http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf For this reason I'd not only strongly argue in favour of using NID_secp521r1 for the ECDH exchange - but I'd actually argue against using ECDHE altogether with curve P256 because of the aforementioned issue. A problem with this is that both changes, but especially the increased DH pool size, also result in increased server load which may not be desirable. This could be solved by having a configuration directive to specify a path to a DH params file. Lastly, I'd like to note that I do not regularly follow this list. I apologize in advance for any conventions on this mailing list I haven't followed. -- Patrick Godschalk arg...@argure.nl GPG: https://argure.nl/identity/ecc14594.asc This e-mail falls under the CC0 1.0 Universal Public Domain Dedication. -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1379807185.20367.18.ca...@alderaan.argure.nl
