It'd be hard to hide an insertion if the devs all dig into the hashes of commits of their own local repos and compare, right? Even a broken hash would require changing input, so they could go an extra step and verify each commit using another hash algo, if they were feeling super-paranoid.

I'm still on the fence: this is the kind of error C is infamous for after all.

On 11 April 2014 14:07:09 GMT+01:00, tpb-crypto@laposte.net wrote:
Message du 11/04/14 05:44
De : dan@geer.org
It makes me wonder if the NSA was involved in inserting this bug into
OpenSSL clients and servers.

If they did it, someone got a promotion. If they are as surprised
as you are, someone got fired.

In the meantime, tell me that gcc is so compact and well vetted that
there is no room in it for insertions...


This article makes an interesting point, we got to dig a bit more from our pockets:

http://www.wired.com/2014/04/heartbleedslesson/

The second point I wish to make is the surprise by which the original developer took the issue. Maybe, just maybe, he did not create that flaw at all.

It could have been inserted into the OpenSSL repository through a backdoor ... or why would the spies by so interested in hacking professors that deal with crypto and whose word is trusted by the masses? Like they did to a Belgian cryptographer? Was that fellow nerd a turrist of sorts?

It may be possible that Segelmann did his job correctly, that the reviewer did his job correctly, but someone unknown may have changed it just a little bit before delivery.


Besides funding projects like OpenSSL better, we should start considering the security of the repositories themselves.

What ya fellow coders think?

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.