Commit graph

420 commits

Author SHA1 Message Date
Richard Levitte
14565bedaf Some functions, like strdup() and strcasecmp(), are defined in
strings.h according to X/Open.
2001-02-20 19:05:59 +00:00
Richard Levitte
cf1b7d9664 Make all configuration macros available for application by making
sure they are available in opensslconf.h, by giving them names starting
with "OPENSSL_" to avoid conflicts with other packages and by making
sure e_os2.h will cover all platform-specific cases together with
opensslconf.h.

I've checked fairly well that nothing breaks with this (apart from
external software that will adapt if they have used something like
NO_KRB5), but I can't guarantee it completely, so a review of this
change would be a good thing.
2001-02-19 16:06:34 +00:00
Ben Laurie
4978361212 Make depend. 2001-02-04 21:06:55 +00:00
Dr. Stephen Henson
29e1fdf3f2 Avoid compiler warnings in hw_ubsec.c: unused static
functions and signed/unsigned mismatch.

This will of course change if some of the unused functions
suddenly get used...
2000-12-27 19:20:14 +00:00
Geoff Thorpe
016d7d250a This is an engine contributed by Broadcom - it is meant to support the
BCM5805 and BCM5820 units. So far I've merely taken a skim over the code
and changed a few things from their original contributed source
(de-shadowing variables, removing variables from the header, and
re-constifying some functions to remove warnings). If this gives
compilation problems on any system, please let me know. We will hopefully
know for sure whether this actually functions on a system with the relevant
hardware in a day or two.  :-)
2000-12-14 21:41:55 +00:00
Richard Levitte
c28500900e On Windows, Rainbow uses _stdcall convention under Windows.
Spotted by plin <plin@rainbow.com>
2000-12-05 08:16:25 +00:00
Geoff Thorpe
8bfc8f934f I have no idea how this comment got there, but it's certainly not
applicable to ENGINE_ctrl()
2000-11-16 00:17:11 +00:00
Geoff Thorpe
ef02b10a16 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.
2000-11-16 00:15:50 +00:00
Richard Levitte
159564ae9f Modify () to (void), since that's what is actually defined in the
engine structure, and some ANSI C compilers will complain otherwise.
2000-11-14 15:33:06 +00:00
Ulf Möller
6a8ba34f9d in some new file names the first 8 characters were not unique 2000-11-12 22:32:18 +00:00
Richard Levitte
ccb9643f02 Remove references to RSAref. The glue library is but a memory to fade
away now...
2000-11-08 17:51:37 +00:00
Richard Levitte
f971ccb264 Constify DH-related code. 2000-11-07 14:30:37 +00:00
Richard Levitte
a4aba800d9 Constify DSA-related code. 2000-11-07 13:54:39 +00:00
Richard Levitte
669cefdd35 Make sure ERR_get_error() is declared. 2000-11-07 13:53:21 +00:00
Richard Levitte
74489a3668 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.
2000-11-07 13:21:09 +00:00
Richard Levitte
10e473e930 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?
2000-11-06 22:15:50 +00:00
Geoff Thorpe
ee78e1fc8b Richard moved hw_nuron.c over to DSO-land recently, so this include isn't
needed now.
2000-11-03 17:09:19 +00:00
Ulf Möller
864170286a Minor corrections (HPUX).
From: Lutz Jaenicke <Lutz.Jaenicke@aet.TU-Cottbus.DE>
2000-11-03 16:35:31 +00:00
Richard Levitte
11c0f1201c 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.
2000-11-02 20:33:04 +00:00
Richard Levitte
5270e7025e Merge the engine branch into the main trunk. All conflicts resolved.
At the same time, add VMS support for Rijndael.
2000-10-26 21:07:28 +00:00