For example, all those nice wrappers. But one should really look at the CVS log messages to be taugh a useful lesson. Some of the log messages for our own enlightenment:
trivial one-liner in OpenSSL RT #2569 ignored for 2.5 years.
Just like every web browser expands until it can read mail, every modular library expands until it has its own dlfcn wrapper, and libcrypto is no exception.
12 years ago, olddes.h was used to provide compatibility with libdes. The man page says "Compatibility des functions are provided for a short while" and indeed even the original commit message says "The compatibility functions will be removed in some future release, at the latest in version 1.0." So here we are, a short while later.
Now I've only been an OpenBSD developer for 11 years, one year less than this header has existed, but in that brief time, I've learned a thing or two about deleting obsolete code. It doesn't delete itself. And worse, people will continue using it until you force them onto a better path.
$infile="/home/eay/ssl/SSLeay/MINFO"; I wonder when these scripts were last used...
Same with memcmp, call the system one! It is more likely to be hot in the icache, and is specifically optimized for the platform. I thought these OpenSSL people cared about performance?
strncpy(d, s, strlen(s)) is a special kind of stupid. even when it's right, it looks wrong. replace with auditable code and eliminate many strlen calls to improve efficiency. (wait, did somebody say FASTER?) ok beck
(it should be remembered that the argument to OpenSSL to use its own memory allocator was performance on some platforms)
you do not want to do the things this program does
"A hack to make Visual C++ 5.0 work correctly" ... time to upgrade.
Your operating system memory allocation functions are your friend. If they are not please fix your operating system.
revert. the full horror has only now revealed itself.
Thanks to the knobs in http://tools.ietf.org/html/rfc5746, we have a knob to say "allow this connection to negotiate insecurely". de-fang the code that respects this option to ignore it.
- Why do we hide from the OpenSSL police, dad?
- Because they're not like us, son. They use macros to wrap stdio routines, for an undocumented (OPENSSLUSEAPPLINK) use case, which only serves to obfuscate the code.
It worked because it was never called.
- RAND_seed is now DEPRECATED
- Even passing a digest in as entropy is sloppy.
But apparently the OpenSSL guys could find no objects of lesser value to pass to the pluggable random subsystem, and had to resort to private keys and digests. Classy.
Fully kill FIPS API. Forcible certification conflicts with the goals of a free software project. ok beck deraadt
todo: do not leave 15 year old todo lists in the tree.
It seems a generation of programmers is aping OpenSSL. We need re-education camps. RAND_ is considered hamful, we should not re-implement it here. "fire bomb it" - tedu@, "dresdenizing" - beck@, "SSLaughterhouse five" miod@
I have intentionaly left some of them out of this list.
Do you think this looks like unfair bashing? Do you think we users should not complain? That there is nothing to expect since OpenSSL is available for free? Even more since we are not specialists? Of course, we are not entitled to anything, but consider the following opinion: giving something away for free is not an excuse for bad design and coding practice. Many who have taken responsibility in IETF and OpenSSL have accumulated mistakes that should not have happened for such a critical piece of software. The mailling lists, the meeting minutes, the commits, the bug reports are all publicly available, one can dig through them, and what is to be seen is bad. There is, at the very least, a lot to learn from this fiasco. So, please, let us users take good note of all this and go where we think is best fitting our interest.
Quoting Miod Vallat on undeadly:
This is about realizing belatedly that code we thought of good quality was not even decent, and ended up becoming too complex and unmaintainable.
So now we are hurrying to remove everything in the way of exposing the concrete guts of the code, fixing the bad practices inherited from the way we were doing security 15+ years ago, and making sure we do not break basic functionality in the process.
We have a good six weeks of work ahead of thus, simply doing this.
Then will come a second time, when we can add the few features we deem desirable, and work on spotting and fixing bugs. Then we'll need to concentrate on getting a new OpenBSD release out of the door.
Only after that, and if the above work succeeds, will we be able to consider making standalone releases of this new OpenSSL flavour, and consider working on a portable version for the other Unix-like operating systems out there.
We have people actually showing the way, and others believing that throwing more money at the OpenSSL project will solve their problem. If lack of founding was a reason for writing bad code, we users would not enjoy such an OpenSSH.