Re: [discussion] Release 2.0.65 [the final frontier]
Hi, Maybe the simple option is to do the final release with the old/existing bundled APR, but put a foot note in the release notes that the newer APR v1.4.8/1.5.2 has been confirmed to successfully work with 2.0.65. This way it may give confidence to anyone who is stuck on 2.0.x for some reason to use the newer APR/APR-util if needs be. Regards, Mike On 02/07/2013 13:06, Guenter Knauf wrote: Hi Bill, On 02.07.2013 01:47, wr...@rowe-clan.net wrote: I am not at all concerned whether APR 0.9 is released again or not since folks had years to take that up in our discussions of putting httpd 2.0 to bed, yet nobody so much as suggested a release, nevermind some volunteer to act on it. true; but I thought that most of us probably forgot about that we bundle APR/APU with 2.0.x - like I did; the lack of APR/APU fixes came only to my attention when I was on building the 2.0.65 binaries ... but since nobody else expressed an oppinion about then thats fine, and I shut up. or if you have concurred with the group consensus to let this story end as of Jun 2013. I have. Just did put the NetWare bins up; go ahead and release. Gün.
Re: [discussion] Release 2.0.65 [the final frontier]
Hi Oh I see - I had not realised this. In that case, I agree that sticking with 0.9.x is the only sensible option at this point in time :) Mike On 02/07/2013 14:35, Jeff Trawick wrote: On Tue, Jul 2, 2013 at 8:53 AM, MikeM michaelm12-asfbugzi...@aquaorange.net mailto:michaelm12-asfbugzi...@aquaorange.net wrote: Hi, Maybe the simple option is to do the final release with the old/existing bundled APR, but put a foot note in the release notes that the newer APR v1.4.8/1.5.2 has been confirmed to successfully work with 2.0.65. This way it may give confidence to anyone who is stuck on 2.0.x for some reason to use the newer APR/APR-util if needs be. APR/APR-util 1.x won't work with httpd 2.0.x. Someone continuing to use 2.0.x will need to hand-pick or backport fixes from apr/apr-util 0.9.x or later levels. But then they'll have to backport fixes from httpd too. The line was drawn at slightly different places for httpd vs. apr/apr-util, but the long term picture is the same: There is effort to remain on httpd 2.0.x if you want to pick up any code fixes, and the recommendation is clear. Regards, Mike On 02/07/2013 13:06, Guenter Knauf wrote: Hi Bill, On 02.07.2013 01:47, wr...@rowe-clan.net mailto:wr...@rowe-clan.net wrote: I am not at all concerned whether APR 0.9 is released again or not since folks had years to take that up in our discussions of putting httpd 2.0 to bed, yet nobody so much as suggested a release, nevermind some volunteer to act on it. true; but I thought that most of us probably forgot about that we bundle APR/APU with 2.0.x - like I did; the lack of APR/APU fixes came only to my attention when I was on building the 2.0.65 binaries ... but since nobody else expressed an oppinion about then thats fine, and I shut up. or if you have concurred with the group consensus to let this story end as of Jun 2013. I have. Just did put the NetWare bins up; go ahead and release. Gün. -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: Diffie-Hellman group parameters 1024 bit and Perfect Forward Secrecy
Hi, I agree that the configuration of DH parameters should be possible from within Apache. Ideally the configuration should allow the size of random DH Parameters to be chosen and also allow the user to provide a preconfigured DH Parameter file. This patch should be included into 2.2 and 2.4, and of course 2.5-dev :) Many thanks, Mike On 28/06/2013 08:46, Hanno Böck wrote: Hi, There has been lately some attention to perfect forward secrecy in TLS, mainly due to an article on netcraft: http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html What worries me is that apache still fixes the DH group size to 1024 bit. If one uses an RSA key with, e.g., 2048 bit, then using a DHE TLS cipher will actually downgrade the security of the connection. DLP or factoring-based public key cryptography with 1024 bit has been known to be potentially week for quite some time now. NIST recommended to phase out 1024 bit keys by 2010. (we don't have a key here, but the security of a DHE group with 1024 bit is equivalent to a 1024 bit DSA key) There's been a patch in bugzilla for a while to allow user-defined DH parameters, however it hasn't gotten any attention by apache developers yet: https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 I'd like to ask apache devs to raise some attention to this issue. I think user-defined dh groups would be a good thing, but probably the default should also be raised to e.g. 2048 bit. cu,
[PATCH 53899] SSL_OP_ALL and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
Hi, I've added three patch files to bug 53899 (https://issues.apache.org/bugzilla/show_bug.cgi?id=53899) which add a new configuration option (SSLEnableEmptyFragments) to Apache. When this option is enabled the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS bit is cleared from SSL_OP_AL. The three files all contain the same patch - thus only one needs to be applied. The code ones both apply cleanly, but I included separate ones for 2.5-dev and 2.4.4 for completeness. There is a third one which includes a documentation update against 2.5-dev, but I'm not sure if it was sufficient or correct. I'm not entirely sure what and where to update for documentation purposes. All three patches include the same code update - only one needs to be applied. Please consider this patch for inclusion. Mike
