On Fri, Apr 11, 2014 at 9:37 AM, Cathal Garvey (Phone) <cathalgarvey@cathalgarvey.me> wrote:
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.
The detection would often occur with a scrub type of routine maintenance check or automatically depending on the system. And unfortunately there are many critical repos that essentially refuse to move to a revcontrol system that employs signable hashes/merkle such that a cracked repo or even bitrot could be detected. Often out of such non claims [1] as workflow and effort to switch. FreeBSD is an example of such a key repo. http://www.git-scm.com/ http://www.git-scm.com/about/distributed [1] Considering potential the core-outwards architectural integrity benefits, among others.
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?