that were never part of the engine framework.
The aep and sureware implementations are taken directly from 0.9.6c
[engine] and have been modified to fit the newer engine framework and
to be possible to build shared libraries of.
The aep implementation has gone through quite a bunch of tests and is
cleaned up (there were some misunderstandings in it about how to use
locks).
The sureware hasn't been tested at all in this incarnation and is
basically a quick hack to get it to compile properly.
functions in ui_compat. This gave reason to rework that part more
thoroughly, so here are the changes made:
1. Add DES_read_password() and DES_read_2passwords() with the same
functionality as the corresponding old des_ functions, as a
convenience to the users.
2. Add UI_UTIL_read_pw_string() and UI_UTIL_read_pw() with the
functionality from des_read_pw_string() and des_read_pw(), again as
a concenience to the users.
3. Rename des_read_password(), des_read_2passwords(),
des_read_pw_string() and des_read_pw() by changing des_ to
_ossl_old_des_, and add the usual mapping macros.
4. Move the implementation of des_read_password() and
des_read_2passwords() to the des directory, since they are tightly
tied to DES anyway.
This change was inspired by a patch from Assar Westerlund <assar@sics.se>:
There are some functions that didn't get the kick-away-old-des-and-
replace-des-with-DES action. Here's a patch that adds DES_ and des_
(in des_old.h) versions of des_read_pw_string et al. This patch
includes some of the first des_old.h semi-colon macro fixes that I've
already sent.
This patch makes the macros in des_old.h actually pretend to be
functions.
There's no reason not to define _ossl_old_crypt when using
PERL5/FreeBSD/darwin/Next, since it makes using crypt and including
des.h break. Here's a trivial patch.
This patch fixes some of the typos used in macro names in des_old.h
and the number of arguments for some of them.
* When linking against shared libraries, the absolute path is remembered.
- When linking against -L.., '..' is remembered inside the executable,
so it will fail after "make install" or when not called from inside the
"apps/" subdirectory of the build tree.
- When using the "+cdp" option of "ld", the ".." information can be
exchanged against $(INSTALL_TOP)/lib. In this case the executable
will however refuse to work before "make install" has been called.
This makes testing the 'openssl' executable a problem.
* Solution 1:
Relink the "openssl" executable, when "make install" is called.
This would however require significant changes to the toplevel Makefile
and the apps/ Makefile.
* Solution 2:
Statically link against libssl and libcrypto, so that the "openssl"
executable is no longer dependant on the openssl shared libraries.
Select option 2 for HP-UX 32bit, as this requires the smallest change.
[See
Message-ID: <3BB07999.30432AD2@celocom.com>
Date: Tue, 25 Sep 2001 13:33:29 +0100
From: Dr S N Henson <drh@celocom.com>
To: openssl-dev@openssl.org
Subject: Re: Error in v3_purp.c
]