handlers were previously getting called before (and after, respectively)
the "ex_data" structures - this meant init() had very little that it
could initialise, and finish() had very little it could cleanup.
'ranlib' doesn't always run on some systems. That's actually
acceptable, since all that happens if it fails is a library with an
index, which makes linking slower, but still working correctly.
test was never triggered due to an off-by-one error.
In s23_clnt.c, don't use special rollback-attack detection padding
(RSA_SSLV23_PADDING) if SSL 2.0 is the only protocol enabled in the
client; similarly, in s23_srvr.c, don't do the rollback check if
SSL 2.0 is the only protocol enabled in the server.
could be done automagically, much like the numbering in libeay.num and
ssleay.num. The solution works as follows:
- New object identifiers are inserted in objects.txt, following the
syntax given in objects.README.
- objects.pl is used to process obj_mac.num and create a new
obj_mac.h.
- obj_dat.pl is used to create a new obj_dat.h, using the data in
obj_mac.h.
This is currently kind of a hack, and the perl code in objects.pl
isn't very elegant, but it works as I intended. The simplest way to
check that it worked correctly is to look in obj_dat.h and check the
array nid_objs and make sure the objects haven't moved around (this is
important!). Additions are OK, as well as consistent name changes.
Also, "make update" has added some missing functions to libeay.num,
updated the TABLE for the alpha changes, and updated thousands of
dependancies that have changed from recent commits.
was a really bad idea. For example, the following:
#include <x509.h>
#include <bio.h>
#include <asn1.h>
would make sure that things like ASN1_UTCTIME_print() wasn't defined
unless you moved the inclusion of bio.h to above the inclusion of
x509.h. The reason is that x509.h includes asn1.h, and the
declaration of ASN1_UTCTIME_print() depended on the definition of
HEADER_BIO_H. That's what I call an obscure bug.
Instead, this change makes sure that whatever header files are needed
for the correct process of one header file are included automagically,
and that the definitions of, for example, BIO-related things are
dependent on the absence of the NO_{foo} macros. This is also
consistent with the way parts of OpenSSL can be excluded at will.
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.
"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.
initialised, at which point an appropriate default was chosen. This meant a
call to RSA_get_default_method might have returned FALSE.
This change fixes that; now any called to RSA_new(), RSA_new_method(NULL), or
RSA_get_default_method() will ensure that a default is chosen if it wasn't
already.
library, the output buffer always is large enough, but if the tlen
parameter is there, it should be checked in the interest of clarity,
as proposed by David Sacerdote <das33@cornell.edu>.
returns int (1 = ok, 0 = not seeded). New function RAND_add() is the
same as RAND_seed() but takes an estimate of the entropy as an additional
argument.
OpenSSL is compiled with NO_RSA, no RSA operations can be used: including
key generation storage and display of RSA keys. Since these operations are
not covered by the RSA patent (my understanding is it only covers encrypt,
decrypt, sign and verify) they can be included: this is an often requested
feature, attempts to use the patented operations return an error code.
This is enabled by setting RSA_NULL. This means that if a particular application
has its own legal US RSA implementation then it can use that instead by setting
it as the default RSA method.
Still experimental and needs some fiddling of the other libraries so they have
some options that don't attempt to use RSA if it isn't allowed.
in cryptlib.h (which is often included as "../cryptlib.h"), then the
question remains relative to which directory this is to be interpreted.
gcc went one further directory up, as intended; but makedepend thinks
differently, and so probably do some C compilers. So the ../ must go away;
thus e_os.h goes back into include/openssl (but I now use
#include "openssl/e_os.h" instead of <openssl/e_os.h> to make the point) --
and we have another huge bunch of dependency changes. Argh.
