On Sun, Sep 25, 2011 at 2:59 AM, Magnus Fromreide <[email protected]>wrote:
> On Sat, 2011-09-24 at 09:52 +0200, Bart Van Assche wrote:
> > On Thu, Sep 22, 2011 at 5:49 PM, Wes Hardaker
> > <[email protected]> wrote:
> > > >>>>> On Thu, 22 Sep 2011 17:05:46 +0200, Bart Van Assche <
> [email protected]> said:
> > > BVA> If EVP_MD_CTX would grow larger in the future, a crash could be
> triggered by
> > > BVA> upgrading too. That's actually what several (Windows) users have
> reported
> > > BVA> when they tried to run the Net-SNMP 5.4 binaries (built against
> OpenSSL
> > > BVA> 0.9.something) on a system where OpenSSL 1.0 was installed.
> > >
> > > We have two situations:
> > >
> > > 1) people compiling the source themselves against an unknown OpenSSL.
> > > If we want to support < 0.9.6, then Dave's solution allows for that.
> > > The only time something would break would be if the user upgraded
> > > from 0.9.6 to something else without recompiling.
> > >
> > > 2) people using our distributed binaries (eg, on windows). I think it's
> > > likely safe to say we'll only be producing binaries with 0.9.7 or
> > > later and thus the original function would be used from OpenSSL,
> > > after applying your proposed patch, so that users upgrading or using
> > > a different OpenSSL won't be affected by that particular malloc size
> > > change.
> > >
> > > In actuality, though, I actually think that this is not necessarily the
> > > only problem we'll run into. OpenSSL is not known for being backwards
> > > compatible and I suspect if you asked them if it was safe to upgrade
> > > their library to a new version without recompiling all the software
> > > linked against it they'd say "no way; please recompile".
> >
> > This follow-up patch should restore OpenSSL 0.9.6 compatibility:
> >
> > ---
> > diff --git a/configure.d/config_os_libs2 b/configure.d/config_os_libs2
> > index 22ab764..74aba29 100644
> > --- a/configure.d/config_os_libs2
> > +++ b/configure.d/config_os_libs2
> > @@ -277,6 +277,14 @@ if test "x$tryopenssl" != "xno" -a "x$tryopenssl"
> > != "xinternal"; then
> > AC_CHECK_LIB(${CRYPTO}, AES_cfb128_encrypt,
> > AC_DEFINE(HAVE_AES_CFB128_ENCRYPT, 1,
> > [Define to 1 if you have the `AES_cfb128_encrypt'
> > function.]))
> > +
> > + AC_CHECK_LIB(${CRYPTO}, EVP_MD_CTX_create,
> > + AC_DEFINE([HAVE_EVP_MD_CTX_CREATE], [],
> > + [Define to 1 if you have the `EVP_MD_CTX_create'
> function.]))
> > +
> > + AC_CHECK_LIB(${CRYPTO}, EVP_MD_CTX_destroy,
> > + AC_DEFINE([HAVE_EVP_MD_CTX_DESTROY], [],
> > + [Define to 1 if you have the `EVP_MD_CTX_destroy'
> function.]))
>
> Is there any version of OpenSSL that provides only one of create and
> destroy?
>
Not that I know of. Is your concern to minimize the number of configure
tests ? How about defining both HAVE_EVP_MD_CTX_CREATE and
HAVE_EVP_MD_CTX_DESTROY if EVP_MD_CTX_create() has been detected ?
Bart.
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
