Geoff Thorpe [Wed, 31 May 2000 15:28:01 +0000 (15:28 +0000)]
All the little functions created by the IMPLEMENT_STACK_OF() macro will
cast their type-specific STACK into a real STACK and call the underlying
sk_*** function. The problem is that if the STACK_OF(..) parameter being
passed in has a "const *" qualifier, it is discarded by the cast.
I'm currently implementing a fix for this but in the mean-time, this is
one case I noticed (a few type-specific sk_**_num() functions pass in
const type-specific stacks). If there are other errors in the code where
consts are being discarded, we will similarly not notice them. yuck.
Declare ciphers in terms of macros. This reduces
the amount of code and places each block cipher EVP
definition in a single file instead of being spread
over 4 files.
Declare ciphers in terms of macros. This reduces
the amount of code and places each block cipher EVP
definition in a single file instead of being spread
over 4 files.
Geoff Thorpe [Mon, 29 May 2000 03:17:45 +0000 (03:17 +0000)]
This declaration seems to have been added into the header file accidently.
There's no trace of it being implemented and it doesn't seem to have been
intended given that it is prototyped with a BIO yet there was a BIO-
specific version added in at the same time.
Change functions like EVP_EncryptUpdate() so they now return a
value. These normally have software only implementations
which cannot fail so this was acceptable. However ciphers
can be implemented in hardware and these could return errors.
Richard Levitte [Thu, 18 May 2000 21:22:50 +0000 (21:22 +0000)]
Add a new file where all the standards and other documents that we try
to adhere to are listed. It should be regarded as a complement to
whatever is out on the web, including the docs in http://www.openssl.org/
Bodo Möller [Thu, 11 May 2000 23:10:27 +0000 (23:10 +0000)]
When open()ing 'file' in RAND_write_file, don't use O_EXCL.
This is superfluous now that we don't have to avoid creating
multiple versions of the file on VMS (because older versions
are now deleted).
Richard Levitte [Tue, 2 May 2000 13:36:50 +0000 (13:36 +0000)]
In Message-ID: <003201bfb332$14a07520$0801a8c0@janm.transactionsite.com>,
"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.
Also, make the memory debugging routines defined and declared with
prototypes, and use void* instead of char* for memory blobs.
And last of all, redo the ugly callback construct for elegance and
better definition (with prototypes).
Richard Levitte [Tue, 2 May 2000 12:35:04 +0000 (12:35 +0000)]
In Message-ID: <003201bfb332$14a07520$0801a8c0@janm.transactionsite.com>,
"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.
Richard Levitte [Tue, 2 May 2000 12:16:01 +0000 (12:16 +0000)]
In Message-ID: <003201bfb332$14a07520$0801a8c0@janm.transactionsite.com>,
"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.
This case in the "dso_unload" handlers should not be reported as an error -
if a DSO_load(NULL,...) operation fails, it will have to call DSO_free() on
the DSO structure it created and that will filter through to this "unload"
call.
If the stack size is "< 1", then the library never actually loaded. To keep
things clean higher up, I'll treat this as a vacuous case without an error.
It makes the error stack easier to follow real world cases, and the error
this ignores was only useful for catching bugs in internal code, not
mismatched calls from applications (which should be handled in the generic
DSO layer).
The handling of DSA_METHOD and DH_METHOD wasn't quite as problematic as
with RSA_METHOD (the **_get_default_methods do set the default value if
it's not set). However, the code had some duplication and was a bit
conter-intuitive.
Previously, the default RSA_METHOD was NULL until the first RSA structure was
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.
This change facilitates name translation for shared libraries. The
technique used is far from perfect and alternatives are welcome.
Basically if the translation flag is set, the string is not too
long, and there appears to be no path information in the string,
then it is converted to whatever the standard should be for the
DSO_METHOD in question, eg;
blah --> libblah.so on *nix, and
blah --> blah.dll on win32.
This change also introduces the DSO_ctrl() function that is used
by the name translation stuff.
Richard Levitte [Sun, 9 Apr 2000 12:04:35 +0000 (12:04 +0000)]
I've always wanted to make the CONF library more adaptable. Here's
the result.
I have retained the old behavior of the CONF_* functions, and have
added a more "object oriented" interface through NCONF_* functions
(New CONF, you see :-)), working the same way as, for example, the
BIO interface. Really, the CONF_* are rewritten so they use the
NCONF_* functions internally.
In addition to that, I've split the old conf.c code into two files,
conf_def.c and conf_api.c. conf_def.c contains the default config
object that reads a configuration file the standard OpenSSL way, as
well as configuration file with Win32 registry file syntax (I'm not
sure I got that one right). conf_api.c provides an API to build other
configuration file readers around (can you see a configuraion file in
XML? I can :-)).
Finally, I've changed the name conf_lcl.h to conf_def.h, since it's
made specifically for that "class" and none others.
I forgot about $openssl_other_defines ... should probably do this
for consistency. Not sure though whether HAVE_DLFCN_H should be
included too? If we go the autoconf route then this probably wouldn't
be included.