Hi, You are welcome. Quiet frankly I think the actual flaw in this matter isn't in the code but sits in front of the computer. Actually it looks like the mindset of many people seems to be flawed in regards to how they think open source development actually works. These mindsets are kind of demanding as such as people think things such as heartbleed should not happen. The contrary is the case. Such things will happen every now and then if the boundary constraints aren't set accordingly (e.g. see: Conway's_law).
Here in this particular case it is said a C developer should never make such trivial mistakes. I even read some statements that OF COURSE such flaws need to happen if somebody does a commit some when around midnight at a new year's eve. That completely neglects how open source development actually works. And it probably means we should stop coding altogether right now, considering the habits many of us actually have :) We all know that OSS is made possible by volunteers where each one probably dedicates his/her personal time to a bunch of different projects. That means OSS developers are usually not committed at a full time basis to be able to work on a single particular domain. That said, I think the boundary constraints for OSS project actually need to be adjusted instead of making OSS developers personally responsible for their mistakes. If the boundary constraints are setup accordingly they will serve as a first line of defense to prevent such "oversights". On a final word. It is as well curious that commercial entities don't seem to audit OSS accordingly in support of deactivating unnecessary features via an appropriate compiler or autoconf flag (here: -DOPENSSL_NO_HEARTBEATS). Actually it took two years until an aduti catch the "oversight". Instead many companies seem to be using either the official binaries without modification or they don't much care about fine tuning compiler options or autoconf flags :) Cheers Daniel On Sat, Apr 12, 2014 at 9:40 AM, Jean-Louis MONTEIRO <[email protected]>wrote: > Thanks Daniel for this interesting and accurate answer. > > > 2014-04-11 21:09 GMT+02:00 dsh <[email protected]>: > > > Hi, > > > > I'd suppose that the OpenSSL version used by APR depends on the OpenSSL > > version provided by the underlying OS too. Additionally that yet doesn't > > say anything about the hearbleed vulnerability cause OpenSSL could have > > been deactivated by the corresponding compile flag > (-DOPENSSL_NO_HEARTBEATS > > ). > > > > The above statement concerning [1] only applies to Windows where each app > > usually ships its own version of OpenSSL as a dependency. As you can see > in > > certain situations this has a major drawback cause now each app > distributor > > must provide a support statement that certifies that the bundled OpenSSL > > version isn't vulnerable or has been updated. > > > > That's one reason why I opted for a TomEE Linux package that doesn't > > redestribute each and every dependency but re-uses those provided by the > OS > > already :) > > > > [1] http://people.apache.org/~mturk/native/1.1.30/ > > > > Cheers > > Daniel > > > > > > > > Cheers > > Daniel > > > > > > On Fri, Apr 11, 2014 at 5:03 PM, frapien <[email protected]> wrote: > > > > > Apache Tomcat Native library 1.1.30 using APR version 1.4.8 using > OpenSSL > > > 1.0.1g you can use from ... > > > > > > http://people.apache.org/~mturk/native/1.1.30/ > > > > > > > > > > > > -- > > > View this message in context: > > > > > > http://openejb.979440.n4.nabble.com/OpenSSL-Version-and-HeartBleed-tp4668702p4668722.html > > > Sent from the OpenEJB Dev mailing list archive at Nabble.com. > > > > > > > > > -- > Jean-Louis >
