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:
     [1]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.

References

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