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.
structures and functions for each stack type. The previous behaviour
can be enabled by configuring with the "-DDEBUG_SAFESTACK" option.
This will also cause "make update" (mkdef.pl in particular) to
update the libeay.num and ssleay.num symbol tables with the number of
extra functions DEBUG_SAFESTACK creates.
The way this change works is to accompany each DECLARE_STACK_OF()
macro with a set of "#define"d versions of the sk_##type##_***
functions that ensures all the existing "type-safe" stack calls are
precompiled into the underlying stack calls. The presence or abscence
of the DEBUG_SAFESTACK symbol controls whether this block of
"#define"s or the DECLARE_STACK_OF() macro is taking effect. The
block of "#define"s is in turn generated and maintained by a perl
script (util/mkstack.pl) that encompasses the block with delimiting
C comments. This works in a similar way to the auto-generated error
codes and, like the other such maintenance utilities, is invoked
by the "make update" target.
A long (but mundane) commit will follow this with the results of
"make update" - this will include all the "#define" blocks for
each DECLARE_STACK_OF() statement, along with stripped down
libeay.num and ssleay.num 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.
same one). However, the first will temporarily break things until the
second comes through. :-)
The safestack.h handling was mapping compare callbacks that externally
are of the type (int (*)(type **,type **)) into the underlying callback
type used by stack.[ch], which is (int (*)(void *,void *)). After some
degree of digging, it appears that the callback type in the underlying
stack code should use double pointers too - when the compare operations
are invoked (from sk_find and sk_sort), they are being used by bsearch
and qsort to compare two pointers to pointers. This change corrects the
prototyping (by only casting to the (void*,void*) form at the moment
it is needed by bsearch and qsort) and makes the mapping in safestack.h
more transparent. It also changes from "void*" to "char*" to stay in
keeping with stack.[ch]'s assumed base type of "char".
Also - the "const" situation was that safestack.h was throwing away
"const"s, and to compound the problem - a close examination of stack.c
showed that (const char **) is not really achieving what it is supposed
to when the callback is being invoked, what is needed is
(const char * const *). So the underlying stack.[ch] and the mapping
macros in safestack.h have all been altered to correct this.
What will follow are the vast quantities of "const" corrections required
in stack-dependant code that was being let "slip" through when
safestack.h was discarding "const"s. These now all come up as compiler
warnings.
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.
Change EVP_SealInit() and EVP_OpenInit() to
handle cipher parameters.
Make it possible to set RC2 and RC5 params.
Make RC2 ASN1 code use the effective key bits
and not the key length.
TODO: document how new API works.
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.
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.
enhance and tidy up the EVP interface.
This patch adds initial support for variable length ciphers
and changes S/MIME code to use this.
Some other library functions need modifying to support use
of modified cipher parameters.
Also need to change all the cipher functions that should
return error codes, but currenly don't.
And of course it needs extensive testing...
"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).
"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.
"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.
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).
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.
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.
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.
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.
* "no-dso" option available in Configure so that all DSO methods will
return NULL, overriding any support the platform might otherwise
have built.
* dlfcn_no_h config string now available rather than just dlfcn. This
is for platforms that have dlfcn.h functions but do not have (or
need) the dlfcn.h header file.
variety of platforms. A few are missing, and they will be added in
eventually, but as this is new stuff, it was better to not break lots of
platforms in one go that we can't easily test. The changes to "Configure"
should illustrate how to add support to other systems if you feel like
having a go.
NB: I'll add something shortly to allow you to add "dlfcn.h" support on
those platforms that don't have (or need) a dlfcn.h header file. (The
symbol for Configure will probably by "dlfcn_no_h").
Thanks to Richard Levitte, who is responsible for the dso_dl.c support,
understanding the trickier aspects of the build process, and giving great
feedback on everything else.
[Don't use this stuff if you're easily offended by changes to the
interface or behaviour - it's still work in progress.]
PR:
the build process (an upcoming commit no doubt), and is very much *new*
code - what that means is that it compiles ok - usually. It certainly
doesn't mean it runs well or even properly yet. Please don't muck round
with this unless you're looking to help out and hunt bugs. :-)
Currently this code doesn't have any support for controlling the "load"
behaviour (eg. paths, filename translations, etc). That'll be handled
using DSO_ctrl() and various flags, once we work out a sensible set of
flags.
both a patch level and a beta status. IMHO, it also makes more sense
to have beta status be part of the development status than to have it
be an alternate name for patch levels under special conditions.
See http://www.pdc.kth.se/kth-krb/
Their solution for CRAY is somewhat awkward.
I'll assume that a "short" is 32 bits on CRAY to avoid the
#ifdef _CRAY
typedef struct {
unsigned int a:32;
unsigned int b:32;
} XXX;
#else
typedef DES_LONG XXX;
#endif
This was meant for building individual ciphers separately;
but nothing of this is maintained, it does not work
because we rely on central configuration by the Configure
utility with <openssl/opensslconf.h> etc., so the files
are only wasting space and time.
default yet, I wanna play with it a bit more.
For those who don't know: asprintf() is an allocating sprintf. The
first argument to it is a double indirection to char instead of a
single.
Remove one ampersand so the compiler may complain less.
Make rand() static so it will not conflict with the C RTL.
Make bug() static too, for good measure.
(they don't really exist before version 7), so that solution was toast.
Instead, let's do it the way it's done on Unix, but then remove older
versions of the file.
That new mechanism *may* fail for some unixly formated file spec,
although I wouldn't worry too much about it.
also needed to get around C compilers on VMS that set the symbol limit
to 31 characters. Bot the macros VMS and __VMS are checked, since
there's no real way to know if e_os.h has been included yet.
CRYPTO_num_locks() instead of CRYPTO_NUM_LOCKS!), and correct all the
inconsistencies with the rest of OpenSSL.
At least, this compiles nicely on Linux using PTHREADS. I've done no
other tests so far.
Apparently BN_div_recp reports an error for small divisors
(1,2,4,8,40).
I haven't got mismatches so far. If you can, please run the test
program for a few days (nohup divtest >out& or something), and if it
reports a mismatch, post the output.
claim to be 0.9.5beta1).
(Are the version number examples correct -- the same numerical
code for:
* 0.9.3beta2-dev 0x00903002
* 0.9.3beta2 0x00903002
?)
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>.
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.
aka X509_LOOKUP_load_file(...) is always 0 or 1, not the counter
returned from the recently introduced function X509_load_cert_crl_file.
X509_STORE_load_locations expects X509_LOOKUP_load_file to return 1 on
success, and possibly there's other software that relies on this too.
X is 5120 on 32-bit and 151552 on 64-bit architectures and I varies
from 0 to 4. As result the test was *unreasonably* slow and virtually
impossible to complete on 64-bit architectures (e.g. IRIX bc couldn't
even swallow such long lines).
