Richard Levitte [Tue, 21 Nov 2000 23:32:38 +0000 (23:32 +0000)]
Reimplement bn_div_words, bn_add_words and bn_sub_words for VAX.
I'm a little bit nervous about bn_div_words, as I don't know what it's
supposed to return on overflow. For now, I trust the rest of the
system to give it numbers that will not cause any overflow...
Richard Levitte [Sat, 18 Nov 2000 22:58:26 +0000 (22:58 +0000)]
Remove two bn_wexpand() from BN_mul(), which is a step toward getting
BN_mul() correctly constified, avoids two realloc()'s that aren't
really necessary and saves memory to boot. This required a small
change in bn_mul_part_recursive() and the addition of variants of
bn_cmp_words(), bn_add_words() and bn_sub_words() that can take arrays
with differing sizes.
The test results show a performance that very closely matches the
original code from before my constification. This may seem like a
very small win from a performance point of view, but if one remembers
that the variants of bn_cmp_words(), bn_add_words() and bn_sub_words()
are not at all optimized for the moment (and there's no corresponding
assembler code), and that their use may be just as non-optimal, I'm
pretty confident there are possibilities...
Richard Levitte [Fri, 17 Nov 2000 12:01:55 +0000 (12:01 +0000)]
Make sure BN_DIV2W is not defining when defining it, and remove the
declarations of bn_add_part_words() and bn_sub_part_words() since they
do not exist.
Richard Levitte [Thu, 16 Nov 2000 21:35:41 +0000 (21:35 +0000)]
I've checked again and again. There really is no need to expand a to
4 times it's size when bn_sqr_recursive() won't look farther than the
original length. Thereby, constification is no longer a problem.
Richard Levitte [Thu, 16 Nov 2000 18:59:02 +0000 (18:59 +0000)]
/proc/cpuinfo can have several lines containing the word "type". We want the one that is "type", plain and simple. Caught by Raoul Borenius <borenius@shuttle.de>
Geoff Thorpe [Thu, 16 Nov 2000 00:15:50 +0000 (00:15 +0000)]
Many applications that use OpenSSL with ENGINE support might face a
situation where they've initialised the ENGINE, loaded keys (which are then
linked to that ENGINE), and performed other checks (such as verifying
certificate chains etc). At that point, if the application goes
multi-threaded or multi-process it creates problems for any ENGINE
implementations that are either not thread/process safe or that perform
optimally when they do not have to perform locking and other contention
management tasks at "run-time".
This defines a new ENGINE_ctrl() command that can be supported by engines
at their discretion. If ENGINE_ctrl(..., ENGINE_CTRL_HUP,...) returns an
error then the caller should check if the *_R_COMMAND_NOT_IMPLEMENTED error
reason was set - it may just be that the engine doesn't support or need the
HUP command, or it could be that the attempted reinitialisation failed. A
crude alternative is to ignore the return value from ENGINE_ctrl() (and
clear any errors with ERR_clear_error()) and perform a test operation
immediately after the "HUP". Very crude indeed.
ENGINEs can support this command to close and reopen connections, files,
handles, or whatever as an alternative to run-time locking when such things
would otherwise be needed. In such a case, it's advisable for the engine
implementations to support locking by default but disable it after the
arrival of a HUP command, or any other indication by the application that
locking is not required. NB: This command exists to allow an ENGINE to
reinitialise without the ENGINE's functional reference count having to sink
down to zero and back up - which is what is normally required for the
finish() and init() handlers to get invoked. It would also be a bad idea
for engine_lib to catch this command itself and interpret it by calling the
engine's init() and finish() handlers directly, because reinitialisation
may need special handling on a case-by-case basis that is distinct from a
finish/init pair - eg. calling a finish() handler may invalidate the state
stored inside individual keys that have already loaded for this engine.
Lutz Jänicke [Wed, 15 Nov 2000 18:42:41 +0000 (18:42 +0000)]
Fill in missing information about the string returned from
SSL_CIPHER_description(), as there is no other API function to find
out details about the cipher used besides the number of bits or protocol used.
Lutz Jänicke [Tue, 14 Nov 2000 11:05:10 +0000 (11:05 +0000)]
Some platforms (namely HP-UX) require the 'x' bit set for shared libraries.
For performance reasons, it is also recommended to make the (mmap'ed)
shared library 'read-only'.
-> New permissions for installed shared libraries = 555
This doesn't hurt anybody, provided the installation is performed with
'cp -f' :-)
Lutz Jänicke [Mon, 13 Nov 2000 14:40:07 +0000 (14:40 +0000)]
HP-UX shared libraries do not build any longer, as EX_LIBS contains
"-Wl,+s" instead of +s:
* Hardcoded necessary references to -ldld/-ldl into the build rules and
removed EX_LIBS.
HP-UX records the pathnames of dependent libraries when the shared libs
are built, so that ./libcrypto.sl... is recorded in libssl.sl..., with
"./" not being resolvable when running an application linked against -lssl:
* Build libssl without explicit reference to libcrypto, applications will
be linked with "-lssl -lcrypto" anyway.
Richard Levitte [Tue, 7 Nov 2000 23:43:21 +0000 (23:43 +0000)]
Constification of LHASH. Contributed by "Paul D. Smith" <psmith@gnu.org>
I didn't apply all his patches yet, since I have some hesitance about
unconstifying. To be pondered.
Richard Levitte [Tue, 7 Nov 2000 13:21:09 +0000 (13:21 +0000)]
When ENGINE_by_id() couldn't find the given engine id, it generates an
error. When checking like engine_add() is, those errors are actually
good, so remove them.
Richard Levitte [Mon, 6 Nov 2000 23:16:04 +0000 (23:16 +0000)]
The consequence of constification is that to pass the address to a
pointer to a const double pointe parameter, the pointer must point to
const data as well.
Richard Levitte [Mon, 6 Nov 2000 23:04:15 +0000 (23:04 +0000)]
Constify the RSA parts of the ASN.1 library. Note some ugly casts
that are needed in the ASN.1 macros. Hopefully, we can get rid of
those in an elegant way in the future.
Richard Levitte [Mon, 6 Nov 2000 22:15:50 +0000 (22:15 +0000)]
As a consequence of the BIGNUM constification, the ENGINE code needs a
few small constifying changes, and why not throw in a couple of extras
while I'm at it?
Richard Levitte [Mon, 6 Nov 2000 21:15:54 +0000 (21:15 +0000)]
Constify the BIGNUM routines a bit more. The only trouble were the
two functions that did expansion on in parameters (BN_mul() and
BN_sqr()). The problem was solved by making bn_dup_expand() which is
a mix of bn_expand2() and BN_dup().
Richard Levitte [Mon, 6 Nov 2000 06:52:47 +0000 (06:52 +0000)]
Make sure that shared libraries get the internal name engine with the
full version number and not just 0. This should mark the shared
libraries as not backward compatible. Of course, this should be
changed again when we can guarantee backward binary compatibility.
Richard Levitte [Thu, 2 Nov 2000 20:33:04 +0000 (20:33 +0000)]
Change the engine library so the application writer has to explicitely
load the "external" built-in engines (those that require DSO). This
makes linking with libdl or other dso libraries non-mandatory.
Change 'openssl engine' accordingly.
Change the engine header files so some declarations (that differed at
that!) aren't duplicated, and make sure engine_int.h includes
engine.h. That way, there should be no way of missing the needed
info.
Richard Levitte [Thu, 2 Nov 2000 19:24:48 +0000 (19:24 +0000)]
'openssl engine' can now list engine capabilities. The current
implementation is contained in the application, and the capability
string building part should really be part of the engine library.
This is therefore an experimental hack, and will be changed in the
near future.
Geoff Thorpe [Wed, 1 Nov 2000 23:11:19 +0000 (23:11 +0000)]
This is a demo that performs SSL tunneling (client and/or server) and is
built using an abstracted state machine with a non-blocking IP wrapper
around it. README will follow in the next commit.