Start with
Some of the early change logs for Libre SSL.
A major audit of the ubiquitous OpenSSL web security protocol is set to commence under a US$1.2 million industry commitment to harden open source technologies. OpenSSL is first off the rank under the Linux Foundation’s Core Infrastructure Initiative given its popularity and lack of in-depth security review. "OpenSSL has been …
Why, what's so bad about LibreSSL?
Kernel Normal Form, for a start. Mixing tabs and spaces for indentation is a sign of brain damage.
Personally, considering the attitude of the LibreSSL team, I'd want to look very carefully at any changes they made. It'd likely be more efficient just to review the OpenSSL code myself. (And yes, I've spent quite a bit of time in the OpenSSL sources.)
The Heartbleed bug was not a subtle cryptography error but poor interface design, with two variables representing block size. Even if both variables were desirable, there should have been an 'assert'.
So we may need a redesign rather than a review. Also a zero-tolerance policy for compiler warnings.
"Poor interface design"? It was a failure to check the length of an array. Trivial mistake, trivial fix.
It's hard to see how it could be considered a design rather than an implementation failure, except in the general sense of the liberal use of antipatterns and failure to refactor common code into safe alternatives. And I'd still consider that primarily an implementation issue.
Matt Caswell says on the realisation that coding was "very unusual"
A bizarre evaluation. The OpenSSL source is bad by a number of metrics, but it is not at all unusual for C code, either open-source or proprietary. I've looked at probably hundreds of thousands of lines of C source, from hundreds of sources, over the past 27 years, and the vast majority of it ranges from poor to terrible (in terms of readability, maintainability, etc).
It's possible to write good C code. The rules are pretty straightforward: Know the standard. Use meaningful names. Use whitespace and comments well. Enforce contracts. Use types well, including the types defined by the standard, ADTs (which in C means pointers to incomplete structs), and the const qualifier. Detect and handle errors. Avoid impediments to readability, such as overly-long lines, blocks, and functions. Use macros and conditional compilation judiciously and with restraint.
There are people who write good C code, people like Chris Torek and Richard Heathfield and Peter van der Linden. I believe I do so as well. It requires a certain effort, which most C programmers are apparently not willing to make - largely, I suspect, because they haven't realized the cost of not doing so.