Which is more than a little ridiculous. I've written code for Arduino and even that has strlcat and strlcpy - in fact, I had to fill in replacements for them in order to port the code to run on Linux.
> socklen_t – if your OS doesn’t have socklen_t, it’s either int or size_t. But OpenSSL does horrible contortions to define its own. If the size of socklen_t changes while your program is running, openssl will cope.
This doesn't surprise me; I've had to do runtime detection of socklen_t before. There have been 64-bit platforms (old HP/UX I think?) where different versions of the system libraries had differing opinions about sizeof(socklen_t) when you called accept(). On a little-endian platform this would be ignorable (just always reserve 64 bits and pre-zero it) but on big endian you had to do something like:
Is this part accurate? (from page 8) : "The OpenSSL foundation appears to be a million dollar a year for-profit company doing FIPS consulting gigs. (Incorporated in Maryland)"
That's kind of one of the problems with OpenSSL: The paid work they do may help most of the OpenSSL developers pay their bills, but spending their time writing weird one-off features for enterprise clients is the opposite of conducive to doing important work to maintain the quality of the library.
It was interesting to hear how impenetrable the code for OpenSSL was even for experienced studs like the OpenBSD team that have handled openssh.
OpenSSL has been dragging around EBSDIC support that the killed off. 90% of people under 50 will never even have heard of it, and 99.9% of people would agree that support should have been dropped ages ago, once explained.
DOS support is another Bob mentioned.
DOS support for a program that all about TCP/IP. Y, for anyone that had to live through it DOS with a bunch of drives and HIMEM crap would get ping, telnet and a couple other TCP/IP programs.
Possibly somebody even wrote http server for DOS after it was already dead for 10 years.
I recently (2011ish) got SSH installed and working on DOS. I was writing a DOS utility for a client (who makes high end network cards)—all their manufacturing is done via DOS. I got frustrated at the slow turn around time of sneakernetting my code to the test machine via USB thumb drives and managed to get SSH up enough so that could scp from the network.
You might think DOS is dead (I did), but it still exists (thrives?) at certain places.
It's amazing that the OpenSSL Foundation seems to do so little work on their actual code base give that they actually seem to take donations and have developers.
OpenBSD by comparison gets things done with 10% of the OpenSSL budget?
The current maintainers of OpenSSL have been doing a shitty job. It's not that heartbleed itself was the problem.
OpenSSL scares people away, the code is such a mess. I've looked at it for 5 minutes years ago. You hope to compile it, let alone understand it.
Finally people had to take a look at it, and what they found was a scary unmaintained mess vs other open source projects.
Specifically considering the importance of OpenSSL the maintainers seem to do a terrible job.
As people have mentioned. OpenSSL is basically a "FIPS" consultancy.
On FIPS, this claims it is possible to fix Heartbleed without invalidating FIPS certification because the TLS code is separate from the actual crypto implementation:
http://lwn.net/Articles/596102/
Can you expand on this? Do they have a past history of conflicts?
If not, this project would certainly benefit both *BSD and the Linux community. Although the LibreSSL team is currently concentrated on just targetting OpenBSD, the cleaner code base should make porting easy enough that the work in exchange for a cleaner, more secure and easier to debug code base will be worth it.
It would serve the Linux foundation to keep with a more secure implementation than OpenSSL.
Hm.... I see. I do not know if things often get political with the Linux Foundation.
If they do, then this could definitely be an issue.
If they don't then I can see there benefit for the Linux Foundation in funding both. LibreSSL has the benefits I previously mentioned, and OpenSSL benefits from having all the features that are being cut out by LibreSSL (FIPS probably being the biggest one).
But I can see where the possible conflict could occur. Thanks for clearing things up.
This could lead to some fun arguments, since the Ulrich Drepper rejects the idea of strl{cat,cpy}: http://www.sourceware.org/ml/libc-alpha/2000-08/msg00053.htm...