On Fri, Apr 11, 2014 at 4:30 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2014-04-11 21:42, Andrey Borzenkov wrote:
В Fri, 11 Apr 2014 20:01:53 +0200 "Carlos E. R." <> пишет:
I know little of how the vulnerability works,
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
Thanks.
I love this paragraph:
+++···················· Lessons
What can we learn from this?
I'm a fan of C. It was my first programming language and it was the first language I felt comfortable using professionally. But I see its limitations more clearly now than I have ever before. ····················++-
My C teacher, about two decades ago, warned us /against/ using C. he spent hours stressing problems with C and how unsafe it was. Apparently, he had been doing some type of audit of C compilers for a government agency, I think. He could not talk about the details, but he was scared, and transmitted some of it to us...
I'm not a fan of C. But I have been paid to use it, so I used it.
Having seen, and used, a number of languages in the algol family (FORTRAN,Pascal, BASIC, C/C++/C#, Java, Perl, PHP, &c.), I became aware of the strengths and weaknesses of each early on. It seems to me to be silly to be afraid of any of the languages, but rather of the people who use and abuse them. There are incredibly powerful languages, like C++ and Perl, and then others that begin with the good languages, as it were, and dumb them down (Java, C#, PHP) so more junior and intermediate programmers can be more productive and less dangerous. But, in dumbing dow a language, things one can do in the more powerful languages that some deem too dangerous are simply prohibited (because a language feature it depends on is excluded). Look at what MS did with their 'Managed C++', and their suite of .NET libraries and languages. I have seen some old pros say that you have the dumbed down languages that limit what you can do, and basically protect you from yourself, and then languages like C++ that give you lots of power, along with the ability to shoot yourself in the foot, and then there is Perl, which gives you the power to blow your whole (expletive deleted) leg off. I suppose my favorite languages are C++ (for my number crunching) and perl (for my distributed, secure, programming). One can make business cases for all of the available languages in specific situations. It seems to me that, instead of being afraid of any language, it behooves a pro to be aware of the strengths and weaknesses of all the languages he uses, and select the set thereof that best supports the functional requirements of the project he's working on. In the case of this bug, as in most bugs I have squashed, it is not a problem of a flaw in the language, but rather a mistake in coding, and perhaps an over-sight in the testing regime. His first two recommendations, generally, is the more useful. He also said we ought to: 1) Pay money for security audits of critical security infrastructure like OpenSSL 2) Write lots of unit and integration tests for these libraries 3) Start writing alternatives in safer languages One of the biggest factors in software quality is that those that 'manage' software projects often are unwilling to support sufficient documentation and testing. That costs money (or time in the case of open source products, and there may be a shortage of manpower to get it done right). Software houses generally want the software as inexpensive as possible, and so the usual QA processes get shortchanged, or skipped altogether. His first two recommendations go hand in glove. I have seen too many software houses (and those that hire software development contractors) that provide barely enough resources to do a decent job of prototyping, and fail to fund even basic unit testing. As for his third recommendation, it can be argued that there are no truly safe languages that are useful (although, if someone were to pay me to do so, I might consider ADA, to see if it is both genuinely useful and as safe as I have heard it is), and that one must rely on the expertise of those using whatever language has been selected for the work. My final thought is that nothing is perfect, nor is it reasonable to expect perfection from beings as flawed as are human beings. All we can do is our best, and be diligent in acting appropriately when a flaw is detected. Cheers, Ted -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org