You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Georg v. Zezschwitz" <gv...@2scale.de> on 2005/07/05 14:32:48 UTC
Patch for 2.0.54 + OpenSSL 0.9.8
Hi,
the OpenSSL team will pretty soon release 0.9.8 as stable release.
However, currently 2.0.54 cannot be built with 0.9.8beta6, as
a pem.h-definition has changed. The OpenSSL-team considers this
renaming as a bug correction, so compilation of mod_ssl will
go on to fail.
OpenSSL 0.9.8 will introduce SSL compression (which has in
principle been defined since SSLv3, however, concrete compression
methods like DEFLATE were "RFCed" in May 2004).
I have attached a patch to make mod_ssl compile with OpenSSL 0.9.8,
and also added an SSL variable "SSL_COMP_METHOD" to allow logging
(and other usages) of the negotiated compression method.
Moreover, I have - to my best knowledge - extended the documentation.
Could anybody check this and decide if to include?
I guess quite some confusion will happen if OpenSSL 0.9.8 is
finally out and using it with Apache 2.0.54 fails.
Also, please don't kill the messenger :-) - it is not my decision
to change the OpenSSL include file definition...
Regards,
Georg v.Zezschwitz
Re: Patch for 2.0.54 + OpenSSL 0.9.8
Posted by Georg von Zezschwitz <gv...@garnix.de>.
William A. Rowe, Jr. wrote:
>>I have attached a patch to make mod_ssl compile with OpenSSL 0.9.8,
>>and also added an SSL variable "SSL_COMP_METHOD" to allow logging
>>(and other usages) of the negotiated compression method.
>>
>>
>
>My concern is that older libraries would break under this patch.
>Do we care?
>
Why? There is a verification that
a) there is an OpenSSL version number
b) it is >= 0.9.8
Otherwise "NULL" is returned (which should be right for older versions).
I guess compression might get attractive as soon as the first browsers
support it,
and then people might get quite curious how many clients run compression.
So, I think the variable could be quite interesting.
>I changed the variable name to SSL_COMPRESS_METHOD, to kill the
>ambiguity of 'COMP'. I've also added this to the StdEnvVars, since
>its not unreasonable for a CGI to behave differently, knowing that
>compression is already applied to the stream.
>
>
Absolutely, sorry!
>For that matter, mod_deflate aught to peek at this variable and
>just get out of the way :) Patches welcome.
>
>
I'd like to suggest another patch, too:
Some people might prefer to disable compression for CPU load reasons.
Instead of compiling an OpenSSL version for these needs, a Apache
directive would be helpful.
>Finally you had one small typo, a simple string compare was more
>appropriate than a variable length compare (I was confused what
>you ment, did you want to accept SSL_COMP_ME)?
>
>
No, I made a "Copy&Paste"-flaw... Sorry, a 2nd time.
Cheers,
Georg
Re: Patch for 2.0.54 + OpenSSL 0.9.8
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:19 AM 7/6/2005, Paul Querna wrote:
>William A. Rowe, Jr. wrote:
>>At 07:32 AM 7/5/2005, Georg v. Zezschwitz wrote:
>>
>>>However, currently 2.0.54 cannot be built with 0.9.8beta6, as
>>>a pem.h-definition has changed. The OpenSSL-team considers this
>>>renaming as a bug correction, so compilation of mod_ssl will
>>>go on to fail.
>>
>>I've committed that fix to both 2.0 and 2.1 trees, thank you!
>>In the future please separate each functional change into its
>>own patch.
>
>Whoa there. This should not of been committed to the 2.0 tree
>directly. There was no vote. I didn't see anyone else even give
>it a +1 on the mailing list.
>
>That said, it is a simple change, and I will give it a +1, but
>pleeeeease don't do that, 2.0.x is under RTC.
Fair enough :) But I would not proceed to the 2.0 GA without this
passing muster. That's two, so can Paul and I get another +1?
Patch follows. Votes/Comments?
Bill
--- httpd/httpd/branches/2.0.x/modules/ssl/ssl_toolkit_compat.h (original)
+++ httpd/httpd/branches/2.0.x/modules/ssl/ssl_toolkit_compat.h Wed Jul 6 08:10:36 2005
@@ -99,6 +99,13 @@
#define HAVE_SSL_X509V3_EXT_d2i
#endif
+#ifndef PEM_F_DEF_CALLBACK
+#ifdef PEM_F_PEM_DEF_CALLBACK
+/* In OpenSSL 0.9.8 PEM_F_DEF_CALLBACK was renamed */
+#define PEM_F_DEF_CALLBACK PEM_F_PEM_DEF_CALLBACK
+#endif
+#endif
+
#elif defined (SSLC_VERSION_NUMBER) /* RSA */
/* sslc does not support this function, OpenSSL has since 9.5.1 */
Re: Patch for 2.0.54 + OpenSSL 0.9.8
Posted by Paul Querna <ch...@force-elite.com>.
William A. Rowe, Jr. wrote:
>At 07:32 AM 7/5/2005, Georg v. Zezschwitz wrote:
>
>
>
>>However, currently 2.0.54 cannot be built with 0.9.8beta6, as
>>a pem.h-definition has changed. The OpenSSL-team considers this
>>renaming as a bug correction, so compilation of mod_ssl will
>>go on to fail.
>>
>>
>
>I've committed that fix to both 2.0 and 2.1 trees, thank you!
>In the future please separate each functional change into its
>own patch.
>
Whoa there. This should not of been committed to the 2.0 tree
directly. There was no vote. I didn't see anyone else even give it a
+1 on the mailing list.
That said, it is a simple change, and I will give it a +1, but
pleeeeease don't do that, 2.0.x is under RTC.
-Paul
Re: Patch for 2.0.54 + OpenSSL 0.9.8
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 07:32 AM 7/5/2005, Georg v. Zezschwitz wrote:
>However, currently 2.0.54 cannot be built with 0.9.8beta6, as
>a pem.h-definition has changed. The OpenSSL-team considers this
>renaming as a bug correction, so compilation of mod_ssl will
>go on to fail.
I've committed that fix to both 2.0 and 2.1 trees, thank you!
In the future please separate each functional change into its
own patch.
>I have attached a patch to make mod_ssl compile with OpenSSL 0.9.8,
>and also added an SSL variable "SSL_COMP_METHOD" to allow logging
>(and other usages) of the negotiated compression method.
My concern is that older libraries would break under this patch.
Do we care? I dunno - but just in case this is only committed to
the 2.1 dev branch for now.
I changed the variable name to SSL_COMPRESS_METHOD, to kill the
ambiguity of 'COMP'. I've also added this to the StdEnvVars, since
its not unreasonable for a CGI to behave differently, knowing that
compression is already applied to the stream.
For that matter, mod_deflate aught to peek at this variable and
just get out of the way :) Patches welcome.
Finally you had one small typo, a simple string compare was more
appropriate than a variable length compare (I was confused what
you ment, did you want to accept SSL_COMP_ME)?
The revised patch to 2.0.x is attached. Thanks again!
Bill
Re: Patch for 2.0.54 + OpenSSL 0.9.8
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 04:01 AM 7/6/2005, Maxime Petazzoni wrote:
>> thank you for the patch. It looks appropriate, to me, so I'll
>> commit to 2.1.x and (if I can get two more +1's, folks???) I'll also
>> apply to 2.0.55 before we roll in the next day.
>
>Even though I'm not a commiter, I've take a look at the patch and it
>seems good to me too.
Thanks Sam - We do get slammed, and always appreciate all the
available eyes to review patches!
Bill
Re: Patch for 2.0.54 + OpenSSL 0.9.8
Posted by Maxime Petazzoni <ma...@bulix.org>.
Hi,
> thank you for the patch. It looks appropriate, to me, so I'll
> commit to 2.1.x and (if I can get two more +1's, folks???) I'll also
> apply to 2.0.55 before we roll in the next day.
Even though I'm not a commiter, I've take a look at the patch and it
seems good to me too.
Regards,
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.
Re: Patch for 2.0.54 + OpenSSL 0.9.8
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Georg,
thank you for the patch. It looks appropriate, to me, so I'll
commit to 2.1.x and (if I can get two more +1's, folks???) I'll also
apply to 2.0.55 before we roll in the next day.
Bill
At 07:32 AM 7/5/2005, Georg v. Zezschwitz wrote:
>Hi,
>
>the OpenSSL team will pretty soon release 0.9.8 as stable release.
>
>However, currently 2.0.54 cannot be built with 0.9.8beta6, as
>a pem.h-definition has changed. The OpenSSL-team considers this
>renaming as a bug correction, so compilation of mod_ssl will
>go on to fail.
>
>OpenSSL 0.9.8 will introduce SSL compression (which has in
>principle been defined since SSLv3, however, concrete compression
>methods like DEFLATE were "RFCed" in May 2004).
>
>I have attached a patch to make mod_ssl compile with OpenSSL 0.9.8,
>and also added an SSL variable "SSL_COMP_METHOD" to allow logging
>(and other usages) of the negotiated compression method.
>
>Moreover, I have - to my best knowledge - extended the documentation.
>
>Could anybody check this and decide if to include?
>I guess quite some confusion will happen if OpenSSL 0.9.8 is
>finally out and using it with Apache 2.0.54 fails.
>
>Also, please don't kill the messenger :-) - it is not my decision
>to change the OpenSSL include file definition...
>
>Regards,
>
>
>Georg v.Zezschwitz