The whole world wasn't looking for issues of the particular code Apple compiled against the updated package, they are only looking at the package and perhaps how it might apply to some more widespread things out there, not specific proprietary code or even necessarily all kinds of specific projects. Someone needs to do it for the specific ones--as in the people who are working on them. The whole thing "it shouldn't" or "usually" or whatnot, is exactly where the QA bread and butter is given how often none of that holds up despite it sounding so rational.Usually, fixing a bug of this kind does not change the API behaviour at all (except denying the particular type of attack). To make sure of this, OpenSSL is accompanied by a suite of unit tests which make sure that the framework is behaving as desired.
So while what you are saying is certainly a possibility, its more an academic one. The API is well defined and well understood, and also thoroughly tested after the fix. Sure, it is possible that the fix has introduced another bug, but if the whole world has not found it after testing the new version for quite some time, I doubt that Apple will
You do understand that even a single character change in code can run into some issue with something, right? I mean look at this bug and what cased it, or look at the SSL bug that iOS and OS X had just recently. Yes, the bug isn't in Apple's code, nor is Apple's code directly using the bug somehow, but a new build had to be made to address it even with just a tiny small change, that build was tested and confirmed to be fine, but if you have another project that compiles against it, you still want to test it just to make sure that on some off chance something wasn't affected.
All completely poor excuses to not do a more robust validation and run through additional testing as far as a new build of your own product, at least for any organization that has at least a semi-decent QA way of thinking.This is the heartbleed fix. Please tell me WHAT could go wrong with it. The code is quite straightforward
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db902
Funnily enough, I kind of agree with your reasoning more in regards to the Apple SSL bug. That bug is very trivial but it actually brings a functional change (a certain security check being ignored). So a code originally created and tested agains the tree with this bug could have been potentially broken when the bug is fixed (even though its extremely unlikely) what is actually most scary in that story that Apple apparently didn't have a unit test for that case or that the compiler didn't catch and warn about unreachable code (or that the programmer didn't check the warning). However, all heart bleed does is add an additional buffer overflow check. This change is so trivial that I simply can't see any issues with production code arising out of it, unless that production code would voluntarily cause buffer overflows.
Basically, while you are right theoretically, people update their code again such trivial fixes all the time without any issues.
I do agree that OpenSSL code is kind of... messy
----------
There is a bunch of package managers for OS X such as Homebrew and MacPorts. Not to mention Apple's own softwareupdate tool and App Store.
That said, I already had a case where apt-get upgrade killed my installation
Unfortunately it's the lack of actually practicing the theory that then at least sometimes ends up firing back, and even sometimes is not a good thing for any company/organization out there (even if a lot of them still end up living in that reality). But, yeah, we can certainly agree to disagree on this.
