Avoid the conflict between () and (void)

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

Corrected small bug that could add ',L' when it shouldn't

Add the possibility to use an engine as random byte generator.

Cut'n'paste error corrected

Handle the hwcrhk private key with a bit more consistency.  Also, for the
random numbers generator, always return status 1 since the entropy is
already presumably there...

Some error checking when loading keys

API change.

Change the overall RAND routines to actually make use of engines.
This seems to work, but I'm a little unsure that I got it all right,
and would like this to be reviewed.

New ASN1 functions that just deal with
content octets, not tag+length.

Add the possibility to load prvate and public keys from an engine and
implement it for nCipher hardware.  The interface in itself should be
clear enough, but the nCipher implementation is currently not the
best when it comes to getting a passphrase from the user.  However,
getting it better is a little hard until a better user interaction
method is create.

Also, use the possibility in req, so we can start to create CSR's with
keys from the nForce box.

WARNING: I've made *no* tests yet, mostly because I didn't implement
this on the machine where I have an nForce box to play with.  All I
know is that it compiles cleanly on Linux...

More experiments show that you can set your data segment size soft
limit higher and thereby get through compilation of sha_dgst.c.

Change the FAQ entry a bit, giving the details as I observed them.

Don't initialise the pointers to mutex functions directly in the structure.
This is correctly taken care of by hwcrhk_init().  While we're at it, give
this engine the official name of the library used (CHIL, for Cryptographic
Hardware Interface Library).

Document the change.

I got sick and tired of having to keep track of NIDs when such a thing
could be done automagically, much like the numbering in libeay.num and
ssleay.num.  The solution works as follows:

  - New object identifiers are inserted in objects.txt, following the
    syntax given in objects.README.
  - objects.pl is used to process obj_mac.num and create a new
    obj_mac.h.
  - obj_dat.pl is used to create a new obj_dat.h, using the data in
    obj_mac.h.

This is currently kind of a hack, and the perl code in objects.pl
isn't very elegant, but it works as I intended.  The simplest way to
check that it worked correctly is to look in obj_dat.h and check the
array nid_objs and make sure the objects haven't moved around (this is
important!).  Additions are OK, as well as consistent name changes.

Beautification

Add a blurb on how to solve the problem with failing compiltaion of sha_dgst.c on Alpha True64 Unix

Add PRNGD link.

Update STATUS.

Return bignum '0' when BN_rand is asked for a 0 bit random number.

Fix code structure (if ... else if ... where both parts
may be disabled by preprocessor symbols)

Don't dereference NULL pointers.
Submitted by: bowe@chip.ma.certco.com

Don't let top go below zero!

Use up-to-date functions.

Merge in the latest changes from the main trunk, and extra in apps/speed.c

Give the user the option to measure real time instead of user CPU time.

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

Undo the changes I just made.  I'm not sure what I was thinking of.
The message to everyone is "Do not hack OpenSSL when stressed"...

Document my latest changes.

Make it possible for users of the openssl applications to specify the
EGD should be used as seeding input, and where the named socket is.

Make it possible for people to tell where the EGD socket is through
the RANDEGD environment variable.

That's it, I've seen questions about this one time too many for
today.  Time to add extra info so the poor users know where to
go with their troubles.

Make sure we use /usr/sbin/sysctl, especially since /usr/sbin is not
always in the users $PATH...

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

Added references to RFCs 1421 to 1424, that describe PEM.
Suggested by Randolph Bentson <bentson@grieg.holmsjoen.com>

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.

BSD-style MD5-based password algorithm in 'openssl passwd'.
(Still needs to be tested against the original using sample passwords
of different length.)

Steve fixed up some strange errors introduced into dso_win32.c, and I'm
just converting some spaces to tabs from his fix. :-)

Actually comment out the parts of BN_MOD_MUL_WORD that I inteded to
comment out in the previous commit

In BN_mod_exp_mont_word, avoid one application of BN_MOD_MUL_WORD,
and for small 'a' also a couple of calls to
BN_mod_mul_montgomery(r, r, r, ...).

Move add_oid_section to apps.c, so it can be shared by several
applications.  Also, have it and the certificate and key loading
functions take a BIO argument for error output.

Document the change in req.

Change req so the new parameter '-rand file' uses the given file in
addition to the file given through the RANDFILE option or environment
variable.

On case-insensitive systems, the 'install' target gets matched against
the 'INSTALL' file, which means that 9 times of 10, the BlowFish
headers won't get installed.  Avoid this in the same way it's done in
crypto/des/Makefile.ssl, where someone apparently has thought of this...

Move the certificate and key loading functions to apps.c, so they can
be shared by several applications.

Forgot the self-documentation within req.

Document the change in req.

Small change to accept the command line parameter '-rand file'.  This
parameter takes precedence over the RANDFILE option in the
configuration file.

Change mkstack.pl so it now sorts each group
into lexical order. Previously it depended on
the order of files in the directory.

This should now mean that all systems will
agree on the order of safestack.h and will
not change it needlessly and avoid massive
needless commits to safestack.h in future.

It wont however avoid this one :-(

use faster version

* This adds some checking to the 'dlfcn' DSO_METHOD that at least lets
  it cope with OpenBSD which doesn't understand "RTLD_NOW".
* Added the dso_scheme config string entry for OpenBSD-x86 to give it
  DSO support.
* 'make update' that has also absorbed some of Steve's mkstack changes
  for the ASN-related macros.

Fixes for Win32 build.

This is mostly a work around for the old VC++ problem
that it treats func() as func(void).

Various prototypes had been added to 'compare' function
pointers that triggered this. This could be fixed by removing
the prototype, adding function pointer casts to every call or
changing the passed function to use the expected arguments.
I mostly did the latter.

The mkdef.pl script was modified to remove the typesafe
functions which no longer exist.

Oh and some functions called OPENSSL_freeLibrary() were
changed back to FreeLibrary(), wonder how that happened :-)

Handle ASN1_SET_OF and PKCS12_STACK_OF using function
casts in the same way as STACK_OF.

'make update' in the engine branch.

'make update'

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

Avoid unnecessary links and incomplete program file in apps/.

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.

'make update'

Add the missing callback pointer handling functions.
Also, make sure empty slots of the dynamic lock stack are used.
Actually, I'm not really sure this is the right thing to do, and may
remove it, with an endlessly growing stack as result...

The dynamic thread API changed, and so does the documentation.

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

Add OPENSSL_free at the end of CRYPTO_destroy_dynlockid.

Redo the support for dynamic locks.  First of all, it was terribly
insecure, so a static lock is added to isolate the sensitive parts.
Also, to avoid one thread freeing a lock that is used by another, a
reference counter is added.

With the new stack hack macros, there's no need to shorten the names
any more.

Modifications for VMS.

Add support for dynamically created and destroyed mutexes.  This will
be needed in some ENGINE code, and might serve elsewhere as well.
Note that it's implemented in such a way that the locking itself is
done through the same CRYPTO_lock function as the static locks.

WARNING: This is currently experimental and untested code (it will get
tested soon, though :-)).

First of all, with the current macros, we should never get any
type-specific stack function.  Second, even when we don't build any of
those functions, DECLARE_STACK_OF lines should not find themselves
into $def.

Using speaking "variable" names in macros so that e.g. grepping for
sk_whatever_insert and sk_whatever_set immediately reveals the subtle
difference in parameter order.

Change mkstack.pl so that safestack.h is not rewritten when
nothing has changed.

Safe stack reorganisation in terms of function casts.

After some messing around this seems to work but needs
a few more tests. Working out the syntax for sk_set_cmp_func()
(cast it to a function that itself returns a function pointer)
was painful :-(

Needs some testing to see what other compilers think of this
syntax.

Also needs similar stuff for ASN1_SET_OF etc etc.

Change to have a single library that works on both Win9x and WinNT.
As far as I understand, it still needs to be compiled on NT...
Contributed by Arne Ansper <arne@ats.cyber.ee>

typo

In EVP_BytesToKey, replace explicit "8" by "PKCS5_SALT_LEN".

There are compilers that complain if a variable has the same name as a
label. (Reported by Alexei Bakharevski.)

Currently the DSO_METHOD interface has one entry point to bind all
"symbols" including functions (of all prototypes( and variables. Whilst
casting any function type to another violates ANSI C (I believe), it is
a necessary evil in shared-library APIs. However, it is quite
conceivable that functions in general and data symbols could very well
be represented differently to each other on some systems, as Bodo said;

> Since the function/object distinction is a lot more likely to be
> important on real-life platforms supporting DSO *and* it can be quite
> easily done *and* it will silence compilers that don't like
> assignments from void pointers to function pointer variables, why
> not do it?

I agree. So this change splits the "dso_bind" handler in DSO_METHOD
into "dso_bind_var" and "dso_bind_func". Similarly the exported
function DSO_bind() has been split in two. I've also put together
changes for the various DSO_METHOD implementations, but so far only
DSO_dlfcn() has been tested. BTW: The prototype for dso_bind had been
a bit strange so I've taken the opportunity to change its shape (in
both variations).

Also, the README has been updated - particularly with a note about
using customised native name-translation for shared libraries (and that
you can't do it yet).

Add support for the modified SGC key format used in IIS.

This seems to work better with enums...

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. :-)

Make sure that bs is not getting free'd again.
Reported by Robert Eiglmaier <robert.eiglmaier@ixos.de>

Little typo.

Add info on what some other people are currently working on.

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.