- Jun 12, 2000
-
-
Ulf Möller authored
-
Ulf Möller authored
-
- Jun 11, 2000
-
-
Dr. Stephen Henson authored
Documentation correction.
-
Dr. Stephen Henson authored
EVP_DecryptInit() return values. Update docs.
-
Dr. Stephen Henson authored
to support multiple calls. New function to retrieve email address from certificates and requests.
-
- Jun 10, 2000
-
-
Bodo Möller authored
as expected -- maybe it's the different processor, maybe my previous timings were too inaccurate.
-
Bodo Möller authored
Don't give performance gain estimates that appear to be more precise than they really are, especially when they are wrong (2/(1/1.15 + 1) = ca. 1.0698).
-
- Jun 09, 2000
-
-
Bodo Möller authored
-
Richard Levitte authored
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.
-
Bodo Möller authored
-
- Jun 08, 2000
-
-
Bodo Möller authored
-
Bodo Möller authored
-
Bodo Möller authored
says one should use.
-
Bodo Möller authored
marginally faster BN_mod_exp for 1024 bit exponents.
-
Bodo Möller authored
-
Bodo Möller authored
because we're only handling words anyway) in BN_mod_exp_mont_word making it a little faster for very small exponents, and adjust the performance gain estimate in CHANGES according to slightly more thorough measurements. (15% faster than BN_mod_exp_mont for "large" base, 20% faster than BN_mod_exp_mont for small base.)
-
- Jun 07, 2000
-
-
Bodo Möller authored
-
Bodo Möller authored
it is expected).
-
Bodo Möller authored
-
- Jun 06, 2000
-
-
Ulf Möller authored
for use with makefile.one)
-
Andy Polyakov authored
'p' more than once without an intervening sequence point. This behavior is undefined." What it essentially complains about is 'p=p+=1'. Now it's changed to 'p=p+1'...
-
Andy Polyakov authored
MT-support for IRIX 6.x and Alpha-Linux
-
Ulf Möller authored
-
- Jun 05, 2000
-
-
Andy Polyakov authored
Submitted by: Reviewed by: PR:
-
Bodo Möller authored
-
- Jun 04, 2000
-
-
Richard Levitte authored
4.1.4 uses libiberty to define strtoul and strerror.
-
Richard Levitte authored
needed, or size_t won't be defined on SunOS 4.1.4.
-
Richard Levitte authored
-
- Jun 03, 2000
-
-
Ulf Möller authored
Submitted by: John Jarvie <jjarvie@newsguy.com>
-
Ulf Möller authored
-
Ben Laurie authored
-
- Jun 01, 2000
-
-
Richard Levitte authored
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.
-
Ulf Möller authored
-
Ulf Möller authored
-
Richard Levitte authored
-
Ulf Möller authored
Submitted by: Karsten Spang <ks@bellesystems.com>
-
Richard Levitte authored
Contributed by Yoichiro Okabe <okabe@wizsoft.co.jp>
-
Geoff Thorpe authored
libeay.num and ssleay.num.
-
Geoff Thorpe authored
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.
-
Geoff Thorpe authored
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.
-