On May 14, 2014 at 4:03 PM andr...@itship.ch wrote: > > PicoLisp can and might be used to implement security applications.
Of course. > So better use standard proved OS mechanisms and have some more initial > effort to get it running, I think. The standard proved OS mechanism are all different for all the libcs and platforms out there. Testing is advised. Why do you trust the true and tested libc on some unpatched Windows XP over your own, highly vetted and unit-tested custom code? You shouldn't. Veering off topic here ... but sorry, you can't look at OpenSSL, a very, very ill patient, and decide that one single symptom is the cause of its disease. OpenSSL had a bad fever. You decide that it was because OpenSSL made its own socks. You ignore that OpenSSL also smoked crack, ate only at McDonalds, never exercised, drank a lot, and never wore anything but a T-shirt in the winter. Oh, and OpenSSL made the socks not to stay warm, but because OpenSSL thinks that making his own socks makes him run faster. Or something... sorry for the rant, but the take-home from OpenSSL is more like, "don't make your own memory manager without caring even a little bit about if its secure or not, only that its FASTER than some old buggy libc you once encountered 10 years ago." > > The heartbleed bug wouldn't have had such a devastating effect if they > wouldn't have implemented their own memory management. The heartbleed bug wouldn't have existed in the first place if these developing protocols would have been in place: - test on other memory allocators. Just to ensure conformance. - create decent unit tests would (including inputting invalid data, black box testing) - remove the HUGE chunks of unused code (unused code obscures the real code and makes it harder to read) - their custom memory allocator would have cleared out memory on free (like the OpenBSD allocator does) - they would have had any focus security at all I have no problem with the strategy to for instance use a custom allocator with an unsecure default allocator, but defaulting to the system allocator on good platforms like OpenBSD. Disclaimer though, I have actually no particular axe to grind with the actual OpenSSL developers. I have more scorn for those USING OpenSSL in their products. The API is convoluted, the code is questionable. If possible, avoid. Thankfully the OpenBSD developers have stepped up to the challenge and forked openssl: https://en.wikipedia.org/wiki/LibreSSL (That won't fix the API I guess, but at least the security will improve.) Although, for all their bragging about security, they should have done that 10 years ago. But better late than never. Sorry for the bitterness. :) --jakob PS There is also the larger picture. Which is best, having unencrypted communications and knowing it, or having encrypted communications, but unaware of the gaping in holes in security? -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
