>>>>> 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".
-- 
Wes Hardaker
Please mail all replies to [email protected]

------------------------------------------------------------------------------
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

Reply via email to