like Malloc, Realloc and especially Free conflict with already existing names
on some operating systems or other packages. That is reason enough to change
the names of the OpenSSL memory allocation macros to something that has a
better chance of being unique, like prepending them with OPENSSL_.
This change includes all the name changes needed throughout all C files.
yet tighter, and also put some heat on the rest of the library by
insisting (correctly) that compare callbacks used in stacks are prototyped
with "const" parameters. This has led to a depth-first explosion of
compiler warnings in the code where 1 constification has led to 3 or 4
more. Fortunately these have all been resolved to completion and the code
seems cleaner as a result - in particular many of the _cmp() functions
should have been prototyped with "const"s, and now are. There was one
little problem however;
X509_cmp() should by rights compare "const X509 *" pointers, and it is now
declared as such. However, it's internal workings can involve
recalculating hash values and extensions if they have not already been
setup. Someone with a more intricate understanding of the flow control of
X509 might be able to tighten this up, but for now - this seemed the
obvious place to stop the "depth-first" constification of the code by
using an evil cast (they have migrated all the way here from safestack.h).
Fortunately, this is the only place in the code where this was required
to complete these type-safety changes, and it's reasonably clear and
commented, and seemed the least unacceptable of the options. Trying to
take the constification further ends up exploding out considerably, and
indeed leads directly into generalised ASN functions which are not likely
to cooperate well with this.
"Jan Mikkelsen" <janm@transactionsite.com> correctly states that the
OpenSSL header files have #include's and extern "C"'s in an incorrect
order. Thusly fixed.
in SSL_new.
If SSL_OP_SINGLE_DH_USE is set, don't waste time in SSL_[CTX_]set_tmp_dh
on computing a DH key that will be ignored anyway.
ssltest -dhe1024dsa (w/ 160-bit sub-prime) had an unfair performance
advantage over -dhe1024 (safe prime): SSL_OP_SINGLE_DH_USE was
effectively always enabled because SSL_new ignored the DH key set in
the SSL_CTX. Now -dhe1024 takes the server only about twice as long
as -dhe1024dsa instead of three times as long (for 1024 bit RSA
with 1024 bit DH).
don't dynamically create them. This allows using ssltest
for approximate performance comparisons:
$ time ./ssltest -num 50 -tls1 -cert ../apps/server2.pem \
[-no_dhe|-dhe1024dsa|-dhe1024]
(server2.pem contains a 1024 bit RSA key, the default has only
512 bits.) Note that these timings contain both the server's and
the client's computations, they are not a good indicator for
server workload in different configurations.
ssl3_get_message, which is more logical (and avoids a bug,
in addition to the one that I introduced yesterday :-)
and makes Microsoft "fast SGC" less special.
MS SGC should still work now without an extra state of its own
(it goes directly to SSL3_ST_SR_CLNT_HELLO_C, which is the usual state
for reading the body of a Client Hello message), however this should
be tested to make sure, and I don't have a MS SGC client.
designed for that. This removes the potential error to mix data and
function pointers.
Please note that I'm a little unsure how incorrect calls to the old
ctrl functions should be handled, in som cases. I currently return 0
and that's it, but it may be more correct to generate a genuine error
in those cases.
