(I do this far too seldom...)

random numbers generator, always return status 1 since the entropy is
already presumably there...

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.

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

limit higher and thereby get through compilation of sha_dgst.c.

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

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.

may be disabled by preprocessor symbols)

Submitted by: bowe@chip.ma.certco.com

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

the configuration parameter 'no-hw'.

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

it functional :-).

logstream.