Richard Levitte [Wed, 2 Jan 2002 16:55:35 +0000 (16:55 +0000)]
Because Rijndael is more known as AES, use crypto/aes instead of
crypto/rijndael. Additionally, I applied the AES integration patch
from Stephen Sprunk <stephen@sprunk.org> and fiddled it to work
properly with the normal EVP constructs (and incidently work the same
way as all other symmetric cipher implementations).
This results in an API that looks a lot like the rest of the OpenSSL
cipher suite.
Richard Levitte [Wed, 2 Jan 2002 11:06:02 +0000 (11:06 +0000)]
Allow 8-bit characters. This is not really complete, it only marks
characters with the highest bit set as HIGHBIT. We need to expand
this to support the UTF-8 character set properly. However, this
solves the problem that the character 0x80 (which is common in UTF-8)
gets masked to 0x00.
Patch submitted by "Huang Yuzhen" <huangyuzhen@bj.tom.com>
Richard Levitte [Wed, 2 Jan 2002 10:30:07 +0000 (10:30 +0000)]
On Solaris64, cc needs the flag -xarch=v9 when linking shared
libraries. Make a general change to support shared library
linking flags in general.
Noted by Nick Briggs <briggs@parc.xerox.com>
Richard Levitte [Wed, 12 Dec 2001 12:53:13 +0000 (12:53 +0000)]
Implement failover for ubsec. Submitted by Subramanian Ramamoorthy
<sram@broadcom.com> with the following comment:
[...] We have implemented failover (ie, if for some reason that the
hardware fails, the implementation detects this failure and performs
this operation as if no hardware is present, ie, in software) for
sometime now and have tested it here with our hardware. [...]
Richard Levitte [Tue, 4 Dec 2001 11:01:17 +0000 (11:01 +0000)]
UID was never a lable for uniqueIdentifier. However, LDAP and certain
RFCs concerning X.500 directories use UID as a shorter name for the
attribute type userId, which is defined by CCITT and available through
RFCs 1274 and 2247.
Unfortunately, if some applications have used the name "UID" for the
uniqueIdentifier attribute type, they will produce incorrect results.
However, I found it better to follow the standards that are out there
rather than having our own incompatible one.
Richard Levitte [Tue, 4 Dec 2001 07:38:17 +0000 (07:38 +0000)]
I was recently informed that some people wrongly use ssleay.txt as
main documentation, so let's warn them a little more, so the word
"OBSOLETE" really gets understood.
Geoff Thorpe [Thu, 22 Nov 2001 09:13:18 +0000 (09:13 +0000)]
When the "dynamic" ENGINE loads another ENGINE from a shared-library, it
essentially overwrites itself with the new ENGINE, with the exception of
reference counts, ex_data structures, and other 'admin' elements. However
if the new ENGINE doesn't populate certain elements, there's the risk of
the "dynamic" ENGINE's elements showing through - the "cmd_defns" were just
one of the possibilities. This implements a more comprehensive cleanup.
Geoff Thorpe [Thu, 22 Nov 2001 09:01:11 +0000 (09:01 +0000)]
The "openssl" ENGINE is no longer used except as a testing/debugging
device. This change enables it for building as a self-contained "dynamic"
ENGINE, to help testing such mechanisms.
Geoff Thorpe [Thu, 22 Nov 2001 08:48:09 +0000 (08:48 +0000)]
'flags' should only be set inside DSO_load() if constructing a new DSO
object - otherwise we overwrite any flags that had been previously set in
the DSO before calling DSO_load().
Richard Levitte [Thu, 15 Nov 2001 18:48:42 +0000 (18:48 +0000)]
If an engine isn't built in, try loading it as a shareable library
instead. This also makes it possible for users to simply give said
shareable library as argument for the -engine option.
Richard Levitte [Wed, 14 Nov 2001 23:25:46 +0000 (23:25 +0000)]
In a Debian Linux environment, it's not a good idea, apparently, to
manually declare the include directory /usr/include at the same time
as the macro PROTOTYPES is defined with the value 1. Besides,
/usr/include is the standard include directory anyway, so there's no
need to specify it explicitely.
Richard Levitte [Wed, 14 Nov 2001 22:32:19 +0000 (22:32 +0000)]
After loading a dynamic engine, reset the command definitions to the
empty set. This prevents engines that do not set the command
definitions themselves to inherit the ones from "dynamic", which would
otherwise be very confusing.