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:


(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. :)



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

Reply via email to