Check for missing engine name, and also, do not count up the number of given algorithms when an engine is given

p_CSwift_AttachKeyParam actually returns more than one kind of error.  Detect the input size error, treat any that are not specially checked as 'request failed', not as 'provide parameters', and for those, add the actual status code to the error message

Cryptoswitch actually has a few more statuses than SW_OK.  Let's provide the possibility for a better granularity in error checking

Make it possible to turn off compilation of hardware support through
the configuration parameter 'no-hw'.

`make update'

It makes much more sense and is much more consistent with the rest of
OpenSSL to have to opt out hardware support instead of having to opt
it in.  And since the hardware support modules are self-contained and
actually check that the vendor stuff is loadable, it still works as
expected, or at least, so I think...

Give the programmer of extra engines the possibility to actually make
it functional :-).

Make the use of logstream thread-safe.

Use the new control to add a log stream.

When closing the hwcrhk engine, also remove the reference to the
logstream.

Add the possibility to control some engine internals.

Rename 'hwcrhk' to 'ncipher' in all public symbols.  Redo the logging function so it takes a BIO.  Make module-local functions static

The error ENGINE_R_HWCRYPTOHOOK_REPORTS should never have been used

Rename 'hwcrhk' to 'ncipher' in all public symbols

Strange how one line can make a world of difference, particularly when
the one line turns an error return value into a success return value.
:-) "openssl speed -engine hwcrhk rsa1024" now passes through ok.

Get rid of those annoying "?"s from cvs update :-)

Things merged from the main trunk, among others some well needed Win32
fixes.

'make update' in the engine branch.

Now that the branch has been updated with the DSO changes in the head,
correct the DSO-dependant code in the engine code.

Merge ... stuff from main trunk, all conflicts resolved, and addition
of dynamic lock support in the nCipher code.

Merge ... stuff from main trunk, all conflicts resolved, and addition
of dynamic lock support in the nCipher code.

Merge ... stuff from main trunk, all conflicts resolved.

The README for the engine code was quite out of date. Hopefully it is
now less so.

(1) In the atalla initialisation, use the test from Ben's earlier
    Atalla code to see if the accelerator is running.
(2) Turn some spaces into tabs.

Ah, ok so my problem had been typographical rather than philosophical.
It's cute to observe that Atalla having no RSA-specific form of mod_exp
causes a DSA server to achieve about 6 times as many signatures per
second than an RSA server. :-)

Little typo.

This adds Atalla support code to the ENGINE framework. If you have an
Atalla card, you should be able to compile with the "hw-atalla" switch
with "./config" or "perl Configure", and then you can use the command-
line switch "-engine atalla" inside speed, s_cient and s_server (after
checking out note (1)).

Notes:
  (1) I've turned on native name translation when loading the shared-
      library, but this means that the Unix shared library needs to be
      libatasi.so rather than atasi.so. I got around this in my testing
      by creating a symbollic link from /usr/lib/libatasi.so to the real
      library, but something better will be needed. It also assumes in
      win32 that the DLL will be called atasi.dll - but as I don't have
      a win32/atalla environment to try I have no idea yet if this is
      the case.
  (2) Currently DSA verifies are not accelerated because I haven't yet
      got a mod_exp-based variant of BN_mod_exp2_mont() that yields
      correct results.
  (3) Currently the "init()" doesn't fail if the shared library can
      load successfully but the card is not operational. In this case,
      the ENGINE_init() call will succeed, but all RSA, DSA, DH, and
      the two BN_*** operations will fail until the ENGINE is switched
      back to something that does work. I expect to correct this next.
  (4) Although the API for the Atalla card just has the one crypto
      function suggesting an RSA private key operation - this is in
      fact just a straight mod_exp function that ignores all the RSA
      key parameters except the (private) exponent and modulus. This is
      why the only accelerator work is taking place inside the mod_exp
      function and there's no optimisation of RSA private key operations
      based on CRT etc.

Geoff inspired me to nullify some pointers if initialisation went
wrong.  Additionally, just give a new value to hndidx once.

DSO_bind() is effectively a method-specific wrapper for dlopen() or
whatever the underlying API is. It must return (void *) because shared
libraries can expose functions, structures, or whatever. However, some
compilers give loads of warnings about casted function pointers through
this code, so I am explicitly casting them to the right prototypes.

I'm working on Atalla ENGINE code, and the existing bn_exp.c hooks
(initiated by ./config and the presence of SDK headers) are conflicting.

If initialisation fails for any reason, the global function pointers
should be NULL'd out.

This hooks the "hwcrhk" engine Richard just submitted into the default
engine list if HW_NCIPHER is defined. I want to play :-)

- merged in the latest from the main trunk, fixed all conflicts
- implemented nCipher support via the nfhwcrhk library (not well tested).
- make update + make depend

* Migrate the engine code's Malloc + Free calls to the newer
  OPENSSL_malloc and OPENSSL_free.

* 3 "normal" files (crypto/rsa/rsa_lib.c, crypto/dsa/dsa_lib.c
  and crypto/dh/dh_lib.c) had their Malloc's and Free's missed
  when Richard merged the changes across to this branch -
  probably because those files have been changed in this branch
  and gave some grief to the merge - so I've changed them
  manually here.

Merge in code from main trunk to BRANCH_engine.

This commit was manufactured by cvs2svn to create branch 'BRANCH_engine'.

There have been a number of complaints from a number of sources that names
like Malloc, Realloc and especially Free conflict with already existing names
on some operating systems or other packages.  That is reason enough to change
the names of the OpenSSL memory allocation macros to something that has a
better chance of being unique, like prepending them with OPENSSL_.

This change includes all the name changes needed throughout all C files.

Use NO_FP_API.

Don't include <stdlib.h>. In the NO_FP_API case, don't include <stdio.h>.

Small documentation bug, probably a cut'n'paste, corrected.

Bug fix for 64 bit HP-UX.

Submitted by: Karsten Spang <ks@bellesystems.com>

Small fix to enable reading from stdin as well.
Contributed by Yoichiro Okabe <okabe@wizsoft.co.jp>

"make update" + stripping the type-specific stack functions out of
libeay.num and ssleay.num.

This change will cause builds (by default) to not use different STACK
structures and functions for each stack type. The previous behaviour
can be enabled by configuring with the "-DDEBUG_SAFESTACK" option.
This will also cause "make update" (mkdef.pl in particular) to
update the libeay.num and ssleay.num symbol tables with the number of
extra functions DEBUG_SAFESTACK creates.

The way this change works is to accompany each DECLARE_STACK_OF()
macro with a set of "#define"d versions of the sk_##type##_***
functions that ensures all the existing "type-safe" stack calls are
precompiled into the underlying stack calls. The presence or abscence
of the DEBUG_SAFESTACK symbol controls whether this block of
"#define"s or the DECLARE_STACK_OF() macro is taking effect. The
block of "#define"s is in turn generated and maintained by a perl
script (util/mkstack.pl) that encompasses the block with delimiting
C comments. This works in a similar way to the auto-generated error
codes and, like the other such maintenance utilities, is invoked
by the "make update" target.

A long (but mundane) commit will follow this with the results of
"make update" - this will include all the "#define" blocks for
each DECLARE_STACK_OF() statement, along with stripped down
libeay.num and ssleay.num files.

The previous commit to crypto/stack/*.[ch] pulled the type-safety strings
yet tighter, and also put some heat on the rest of the library by
insisting (correctly) that compare callbacks used in stacks are prototyped
with "const" parameters. This has led to a depth-first explosion of
compiler warnings in the code where 1 constification has led to 3 or 4
more. Fortunately these have all been resolved to completion and the code
seems cleaner as a result - in particular many of the _cmp() functions
should have been prototyped with "const"s, and now are. There was one
little problem however;

X509_cmp() should by rights compare "const X509 *" pointers, and it is now
declared as such. However, it's internal workings can involve
recalculating hash values and extensions if they have not already been
setup. Someone with a more intricate understanding of the flow control of
X509 might be able to tighten this up, but for now - this seemed the
obvious place to stop the "depth-first" constification of the code by
using an evil cast (they have migrated all the way here from safestack.h).

Fortunately, this is the only place in the code where this was required
to complete these type-safety changes, and it's reasonably clear and
commented, and seemed the least unacceptable of the options. Trying to
take the constification further ends up exploding out considerably, and
indeed leads directly into generalised ASN functions which are not likely
to cooperate well with this.

This is the first of two commits (didn't want to dump them all into the
same one). However, the first will temporarily break things until the
second comes through. :-)

The safestack.h handling was mapping compare callbacks that externally
are of the type (int (*)(type **,type **)) into the underlying callback
type used by stack.[ch], which is (int (*)(void *,void *)). After some
degree of digging, it appears that the callback type in the underlying
stack code should use double pointers too - when the compare operations
are invoked (from sk_find and sk_sort), they are being used by bsearch
and qsort to compare two pointers to pointers. This change corrects the
prototyping (by only casting to the (void*,void*) form at the moment
it is needed by bsearch and qsort) and makes the mapping in safestack.h
more transparent. It also changes from "void*" to "char*" to stay in
keeping with stack.[ch]'s assumed base type of "char".

Also - the "const" situation was that safestack.h was throwing away
"const"s, and to compound the problem - a close examination of stack.c
showed that (const char **) is not really achieving what it is supposed
to when the callback is being invoked, what is needed is
(const char * const *). So the underlying stack.[ch] and the mapping
macros in safestack.h have all been altered to correct this.

What will follow are the vast quantities of "const" corrections required
in stack-dependant code that was being let "slip" through when
safestack.h was discarding "const"s. These now all come up as compiler
warnings.

is needed.

typo

dh and gendh have been obsoleted by dhparam.

#include <stdio.h> not needed.

#include <stdlib.h> is not needed.

Result of "make update"

This seems to become a FAQ...

sk_***_new_null() seems to be there to avoid exactly this sort of thing
which is a cast between NULL and a function pointer.

sk_value was also suffering from de-const-ification.
Also, add in a couple of missing declarations in pkcs7 code.

config can now detect ARM Linux automagically.
Contributed by Jeremy Norris <jeremy.norris@rebel.com>

strtoul is not used anywhere.

When compiling with /opt/SUNWspro/SC4.2/bin/cc on Solaris, __svr4__ is
not defined, but __SVR4 is.

All the little functions created by the IMPLEMENT_STACK_OF() macro will
cast their type-specific STACK into a real STACK and call the underlying
sk_*** function. The problem is that if the STACK_OF(..) parameter being
passed in has a "const *" qualifier, it is discarded by the cast.

I'm currently implementing a fix for this but in the mean-time, this is
one case I noticed (a few type-specific sk_**_num() functions pass in
const type-specific stacks). If there are other errors in the code where
consts are being discarded, we will similarly not notice them. yuck.

Move Windows seeding functions into a separate file.
They have nothing to do with the particular PRNG (md_rand.c).

Add "FIXME" comment.

Improve PRNG robustness.

More EVP cipher revision.

Change EVP_SealInit() and EVP_OpenInit() to
handle cipher parameters.

Make it possible to set RC2 and RC5 params.

Make RC2 ASN1 code use the effective key bits
and not the key length.

TODO: document how new API works.

Update the relevant parts of the docs with the ENGINE changes. I've also
unbolded a few bits that looked unecessary.

"make update"

Also, corrects the linux-elf-arm config string, it was previously setting
$des_obj = dlfcn :-)

You must have an empty line between =item's

Main trunk changes merged into BRANCH_engine.  There were no
conflicts, which is a good thing.  Propper tagging of merge point
done.

This commit was manufactured by cvs2svn to create branch 'BRANCH_engine'.

Fourth phase EVP revision.

Declare ciphers in terms of macros. This reduces
the amount of code and places each block cipher EVP
definition in a single file instead of being spread
over 4 files.

Fourth phase EVP revision.

Declare ciphers in terms of macros. This reduces
the amount of code and places each block cipher EVP
definition in a single file instead of being spread
over 4 files.

"handle", "h" and even "e" were probably not the best terms to use. The
original idea of "handle" was that it represented a functional reference
to an ENGINE (rather than just a pointer), but on reflection I think
this now looks a little more readable.

Configuration for linux on ARM (contributed by Jeremy Norris
<jeremy.norris@rebel.com>)

Minor corrections to documentation.

* speed processes any/all options passed to it, not just one.
* DH and DSA have no "_get_method()" functions, only RSA does.
* typos.

This adds DSA signature verification to the CryptoSwift support.

"make update"

Tie DSA into the engine framework as with RSA and DH so far. I've verified
this integration with a web-server using CryptoSwift engine code with RSA
and DSA certificates (and with EDH cipher suites).

General tidy up of existing code, and add first half of DSA support for
CryptoSwift (this currently only does signing, verification will be
hooked in shortly).

The engine code has changed the "[get|set]_default_method" functions
a bit, so bring libeay.num up to date.

another warning.

It seems that mktime does what is required here. Certainly timegm() can
not be used because it is not available on all systems (most notably,
win32).

This declaration seems to have been added into the header file accidently.
There's no trace of it being implemented and it doesn't seem to have been
intended given that it is prototyped with a BIO yet there was a BIO-
specific version added in at the same time.

oops.

Update dependencies courtesy of "make update". Changes to libeay.num
coming up soon after some more tinkering.

Submitted by:
Reviewed by:
PR:

This hooks the DH code into the engine framework in the same way that has
already been done for RSA. The others (DSA + RAND) will probably follow
in the near future too, but DH is easiest to test with RSA because one
can just force the use of the EDH cipher-suites.

Provide command line options to s_client and s_server to select an
"engine" to use.

The switch to having an (ENGINE *) handle inside each RSA structure rather
than (RSA_METHOD *) required a couple of functions to change shape. I
didn't really pick the best shape to change RSA_set_method into though. :-)

There's nothing really appropriate to return from RSA_set_method; the
temptation to return an "old handle" fails when you consider that the
caller might ignore the return value and so botch up the reference
counting, this wasn't an issue before because there was no reference
counting.

Third phase of EVP cipher overhaul.

Remove duplicated code in EVP.

Bugfix: clear error queue after ignoring ssl_verify_cert_chain result.

Second phase of EVP cipher overhaul.

Change functions like EVP_EncryptUpdate() so they now return a
value. These normally have software only implementations
which cannot fail so this was acceptable. However ciphers
can be implemented in hardware and these could return errors.

Beginnings of EVP cipher overhaul. This should eventually
enhance and tidy up the EVP interface.

This patch adds initial support for variable length ciphers
and changes S/MIME code to use this.

Some other library functions need modifying to support use
of modified cipher parameters.

Also need to change all the cipher functions that should
return error codes, but currenly don't.

And of course it needs extensive testing...

Update the test program to compile and run with the changes I just made
to ENGINE_new (and ENGINE_get_struct_size).

Prevent calling code from doing the allocation of the ENGINE structure.
This was a bad idea in the first place, in particular it would have made
it trickier to implement error-handling, particularly when shutting down
third-party shared libraries etc.

Added Geoff's latest changes, which seems to mostly be DH stuff and a
README.  Oh, and a test program.

Add code and changes to implement the ENGINE mechanism.  These are the
patches that Geoff had in a patch file in his play directory.

NOTE for openssl-cvs:  THIS IS A CVS BRANCH (BRANCH_engine).  IT IS
NOT FOR THE FAINTHEARTED TO PLAY WITH.  The code works as it is, but
it's not at all sure it ends up in the OpenSSL distributio in this
form, so do not get dependent on it!

Those rsyncing the repository are considered warned!

This commit was manufactured by cvs2svn to create branch 'BRANCH_engine'.

cvs update

typo

Implement SSL_OP_TLS_ROLLBACK_BUG for servers.

Call dh_tmp_cb with correct 'is_export' flag.

Avoid tabs in CHANGES.

Add the target system linux-m68k

Add DSA library string. Workaround for IIS .key file invalid
ASN1 encoding.