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, [email protected] wrote: >> Message du 11/04/14 05:44 >> De : [email protected] >> > 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.
