Fix demo comment: 0.9.9 never released.
[openssl.git] / README.ENGINE
index 1412b22..0ff8333 100644 (file)
@@ -6,7 +6,7 @@
   crypto devices (eg. accelerator cards). This component is called ENGINE,
   and its presence in OpenSSL 0.9.6 (and subsequent bug-fix releases)
   caused a little confusion as 0.9.6** releases were rolled in two
-  versions, a "standard" and an "engine" verion. In development for 0.9.7,
+  versions, a "standard" and an "engine" version. In development for 0.9.7,
   the ENGINE code has been merged into the main branch and will be present
   in the standard releases from 0.9.7 forwards.
 
     gets its own copy of it. As such, multi-threaded code (or code that
     multiplexes multiple uses of 'dynamic' in a single application in any
     way at all) does not get confused by 'dynamic' being used to do many
-    independant things. Other ENGINEs typically don't do this so there is
+    independent things. Other ENGINEs typically don't do this so there is
     only ever 1 ENGINE structure of its type (and reference counts are used
     to keep order). The dynamic ENGINE itself provides absolutely no
     cryptographic functionality, and any attempt to "initialise" the ENGINE
     shared-library that contains the ENGINE implementation, and "NO_VCHECK"
     might possibly be useful if there is a minor version conflict and you
     (or a vendor helpdesk) is convinced you can safely ignore it.
-    "ENGINE_ID" is probably only needed if a shared-library implements
+    "ID" is probably only needed if a shared-library implements
     multiple ENGINEs, but if you know the engine id you expect to be using,
     it doesn't hurt to specify it (and this provides a sanity check if
     nothing else). "LIST_ADD" is only required if you actually wish the
 
        ENGINE *e = ENGINE_by_id("dynamic");
        ENGINE_ctrl_cmd_string(e, "SO_PATH", "/lib/libfoo.so", 0);
-       ENGINE_ctrl_cmd_string(e, "ENGINE_ID", "foo", 0);
+       ENGINE_ctrl_cmd_string(e, "ID", "foo", 0);
        ENGINE_ctrl_cmd_string(e, "LOAD", NULL, 0);
        ENGINE_ctrl_cmd_string(e, "CMD_FOO", "some input data", 0);
 
 
        openssl engine dynamic \
                  -pre SO_PATH:/lib/libfoo.so \
-                 -pre ENGINE_ID:foo \
+                 -pre ID:foo \
                  -pre LOAD \
                  -pre "CMD_FOO:some input data"
 
 
        openssl engine -vvvv dynamic \
                  -pre SO_PATH:/lib/libfoo.so \
-                 -pre ENGINE_ID:foo \
+                 -pre ID:foo \
                  -pre LOAD
 
     Applications that support the ENGINE API and more specifically, the
     "-pre" syntax in the "openssl engine" utility is that some commands
     might be issued to an ENGINE *after* it has been initialised for use.
     Eg. if an ENGINE implementation requires a smart-card to be inserted
-    during intialisation (or a PIN to be typed, or whatever), there may be
+    during initialisation (or a PIN to be typed, or whatever), there may be
     a control command you can issue afterwards to "forget" the smart-card
     so that additional initialisation is no longer possible. In
     applications such as web-servers, where potentially volatile code may
     hand such applications would only have the memory footprint of any
     ENGINEs explicitly loaded using user/admin provided control commands.
     The main advantage of not statically linking ENGINEs and only using
-    "dynamic" for hardare support is that any installation using no
-    "external" ENGINE suffers no unecessary memory footprint from unused
+    "dynamic" for hardware support is that any installation using no
+    "external" ENGINE suffers no unnecessary memory footprint from unused
     ENGINEs. Likewise, installations that do require an ENGINE incur the
     overheads from only *that* ENGINE once it has been loaded.
 
     if OpenSSL itself is built as a shared library. The instructions are
     the same in each case, but in the former (statically linked any
     dependencies on OpenSSL) you must ensure OpenSSL is built with
-    position-independant code ("PIC"). The default OpenSSL compilation may
+    position-independent code ("PIC"). The default OpenSSL compilation may
     already specify the relevant flags to do this, but you should consult
     with your compiler documentation if you are in any doubt.
 
   PROBLEMS
   ========
 
-  It seems like the ENGINE part doesn't work too well with Cryptoswift on Win32.
+  It seems like the ENGINE part doesn't work too well with CryptoSwift on Win32.
   A quick test done right before the release showed that trying "openssl speed
   -engine cswift" generated errors. If the DSO gets enabled, an attempt is made
   to write at memory address 0x00000002.