Make the engine config module always add dynamic ENGINEs
to the list using dynamic_path. This stops ENGINEs which
don't supply any default algorithms being automatically
freed (because they have no references) and allows them
to be accessed by id.
Alternative dynamic loading behaviour can be achieved by
issuing the dynamic ENGINE ctrls separately in the config file.
CONF_modules_unload() now calls CONF_modules_finish()
automatically.
Default use of section openssl_conf moved to
CONF_modules_load()
Load config file in several openssl utilities.
Most utilities now load modules from the config file,
though in a few (such as version) this isn't done
because it couldn't be used for anything.
In the case of ca and req the config file used is
the same as the utility itself: that is the -config
command line option can be used to specify an
alternative file.
Richard Levitte [Wed, 20 Feb 2002 11:57:33 +0000 (11:57 +0000)]
Comparing a pointer (data) with 0 using > is incorrect. The changed
comparison doesn't look right, but at least it compiles. It would be nice
if the one who knows what this is supposed to do changed it to do it correctly
Richard Levitte [Sat, 16 Feb 2002 22:28:31 +0000 (22:28 +0000)]
Since Cygwin is the proper spelling, let's change to that everywhere.
Also, with the change in Configure, it now knows on it's own if
threads are supported or not.
Richard Levitte [Sat, 16 Feb 2002 12:39:07 +0000 (12:39 +0000)]
The AES modes OFB and CFB are defined with 128 feedback bits. This
deviates from the "standard" 64 bits of feedback that all other
algorithms are using. Therefore, let's redo certain EVP macros to
accept different amounts of feedback bits for these modes.
Also, change e_aes.c to provide all usually available modes for AES.
CTR isn't included yet.
Richard Levitte [Sat, 16 Feb 2002 12:03:25 +0000 (12:03 +0000)]
The macro IMPLEMENT_ASN1_FUNCTIONS_const already contains an ending ;,
so do not add one after the expansion, since ANSI C doesn't allow ;;
at this level (or at least, so tells me gcc).
Richard Levitte [Thu, 14 Feb 2002 13:45:26 +0000 (13:45 +0000)]
For some reason, getting the topmost error was done the same way as
getting the bottommost one. I hope I understood correctly how this
should be done. It seems to work when running evp_test in an
environment where it can't find openssl.cnf.
Richard Levitte [Thu, 7 Feb 2002 21:12:08 +0000 (21:12 +0000)]
Because AEP and we used the same AEP_R_ prefix for error reasons,
lets change our prefix to AEPHK_R_. Otherwise, we get very mysterious
errors because we happen to redefine AEP_R_OK and AEP_R_GENERAL_ERROR.
Richard Levitte [Thu, 7 Feb 2002 20:44:14 +0000 (20:44 +0000)]
Add aep and sureware implementations and clean up some error reasons
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.
Richard Levitte [Tue, 5 Feb 2002 17:15:18 +0000 (17:15 +0000)]
With the changed des_old API, let's complete the work by renaming the
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.
Richard Levitte [Tue, 5 Feb 2002 06:02:58 +0000 (06:02 +0000)]
Apply three patches from Assar Westerlund <assar@kth.se>:
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.
Lutz Jänicke [Tue, 29 Jan 2002 16:32:40 +0000 (16:32 +0000)]
HP-UX 32bit:
* 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.
Bodo Möller [Sun, 27 Jan 2002 17:41:12 +0000 (17:41 +0000)]
Undo previous change, X509_check_issued() was correct.
[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
]