On 8/18/2012 2:32 PM, wr...@apache.org wrote:
> --- httpd/httpd/branches/2.2.x/STATUS (original)
> +++ httpd/httpd/branches/2.2.x/STATUS Sat Aug 18 19:32:38 2012
> @@ -145,7 +145,7 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>        http://svn.apache.org/viewvc?view=revision&revision=1225476
>        http://svn.apache.org/viewvc?view=revision&revision=1225792
>      Backport version for 2.2.x of the patches above:
> -      http://people.apache.org/~wrowe/tls11-12-patch-2.2-kbrand-wrowe.1.patch
> +      http://people.apache.org/~wrowe/tls11-12-patch-2.2-kbrand-wrowe.2.patch
>      +1: wrowe, 
>      kbrand: The #define HAVE_TLSV1_X stuff should go to ssl_toolkit_compat.h,
>                [wrowe] disagree, since that API was deprecated 
> @@ -160,6 +160,15 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>              to drop the #ifndef around SSL_PROTOCOL_SSLV2 in ssl_private.h,
>              this should also make some of the other "#if[n]def 
> OPENSSL_NO_SSL2"
>              encapsulations unnecessary.
> +              [wrowe] agreed the patch was wrong, the #ifdef needed to be 
> moved
> +                      up four lines.  Behavior is now correct in patch .2
> +                      Disagree about retaining SSL_PROTOCOL_SSLV2; this is 
> one
> +                      of the most basic design patterns which exists to 
> ensure
> +                      that we don't have some lingering code which is still
> +                      attempting to pursue SSLV2 games, not to mention that
> +                      the various macros and functions in those blocks may
> +                      simply disappear disappear in an OPENSSL_NO_SSL2 build.
> +                      Bad idea, it helps us catch current and future 
> problems.

Thanks for the feedback, Kaspar.  Other than shifting the one #ifdef case to the
correct line of code, I believe the patch is complete, I've tried to state my 
case
for no further changes.  If you would like to propose further changes, I'd 
really
prefer we defer these to 2.2.24-dev so we can T&R already.  I'm pretty sure you
already agree with me that the flexibility to disable a particular cipher in 
light
of exploit research in the very fresh openssl code base makes this patch pretty
critical to release for legacy, as well as stable.

Even if you can give the patch your +1, we still need one more individual to 
chime
in before we can finish this backport, and as I mention, OpenSSL's CVE-2012-2333
suggests that this patch is a showstopper.  Can one more person take a pass 
through
the code, since Stefan didn't have a chance to re-review this week?




Reply via email to