1. 27 4月, 2001 1 次提交
    • G
      This adds 2 things to the ENGINE code. · 0ce5f3e4
      Geoff Thorpe 提交于
       * "ex_data" - a CRYPTO_EX_DATA structure in the ENGINE structure itself
         that allows an ENGINE to store its own information there rather than in
         global variables. It follows the declarations and implementations used
         in RSA code, for better or worse. However there's a problem when storing
         state with ENGINEs because, unlike related structure types in OpenSSL,
         there is no ENGINE-vs-ENGINE_METHOD separation. Because of what ENGINE
         is, it has method pointers as its structure elements ...  which leads
         to;
      
       * ENGINE_FLAGS_BY_ID_COPY - if an ENGINE should not be used just as a
         reference to an "implementation" (eg. to get to a hardware device), but
         should also be able to maintain state, then this flag can be set by the
         ENGINE implementation. The result is that any call to ENGINE_by_id()
         will not result in the existing ENGINE being returned (with its
         structural reference count incremented) but instead a new copy of the
         ENGINE will be returned that can maintain its own state independantly of
         any other copies returned in the past or future. Eg. key-generation
         might involve a series of ENGINE-specific control commands to set
         algorithms, sizes, module-keys, ids, ACLs, etc. A final command could
         generate the key. An ENGINE doing this would *have* to declare
         ENGINE_FLAGS_BY_ID_COPY so that the state of that process can be
         maintained "per-handle" and unaffected by other code having a reference
         to the same ENGINE structure.
      0ce5f3e4
  2. 26 4月, 2001 1 次提交
  3. 19 4月, 2001 1 次提交
    • G
      Some BIG tweaks to ENGINE code. · 40fcda29
      Geoff Thorpe 提交于
      This change adds some new functionality to the ENGINE code and API to
      make it possible for ENGINEs to describe and implement their own control
      commands that can be interrogated and used by calling applications at
      run-time. The source code includes numerous comments explaining how it all
      works and some of the finer details. But basically, an ENGINE will normally
      declare an array of ENGINE_CMD_DEFN entries in its ENGINE - and the various
      new ENGINE_CTRL_*** command types take care of iterating through this list
      of definitions, converting command numbers to names, command names to
      numbers, getting descriptions, getting input flags, etc. These
      administrative commands are handled directly in the base ENGINE code rather
      than in each ENGINE's ctrl() handler, unless they specify the
      ENGINE_FLAGS_MANUAL_CMD_CTRL flag (ie. if they're doing something clever or
      dynamic with the command definitions).
      
      There is also a new function, ENGINE_cmd_is_executable(), that will
      determine if an ENGINE control command is of an "executable" type that
      can be used in another new function, ENGINE_ctrl_cmd_string(). If not, the
      control command is not supposed to be exposed out to user/config level
      access - eg. it could involve the exchange of binary data, returning
      results to calling code, etc etc. If the command is executable then
      ENGINE_ctrl_cmd_string() can be called using a name/arg string pair. The
      control command's input flags will be used to determine necessary
      conversions before the control command is called, and commands of this
      form will always return zero or one (failure or success, respectively).
      This is set up so that arbitrary applications can support control commands
      in a consistent way so that tweaking particular ENGINE behaviour is
      specific to the ENGINE and the host environment, and independant of the
      application or OpenSSL.
      
      Some code demonstrating this stuff in action will applied shortly to the
      various ENGINE implementations, as well as "openssl engine" support for
      executing arbitrary control commands before and/or after initialising
      various ENGINEs.
      40fcda29
  4. 18 4月, 2001 3 次提交
    • G
      Some more tweaks to ENGINE code. · 404f952a
      Geoff Thorpe 提交于
      ENGINE handler functions should take the ENGINE structure as a parameter -
      this is because ENGINE structures can be copied, and like other
      structure/method setups in OpenSSL, it should be possible for init(),
      finish(), ctrl(), etc to adjust state inside the ENGINE structures rather
      than globally. This commit includes the dependant changes in the ENGINE
      implementations.
      404f952a
    • G
      Some more tweaks to ENGINE code. · dcd87618
      Geoff Thorpe 提交于
      Previous changes permanently removed the commented-out old code for where
      it was possible to create and use an ENGINE statically, and this code gets
      rid of the ENGINE_FLAGS_MALLOCED flag that supported the distinction with
      dynamically allocated ENGINEs. It also moves the area for ENGINE_FLAGS_***
      values from engine_int.h to engine.h - because it should be possible to
      declare ENGINEs just from declarations in exported headers.
      dcd87618
    • G
      Some more tweaks to ENGINE code. · d54bf145
      Geoff Thorpe 提交于
      * Constify the get/set functions, and add some that functions were missing.
      
      * Add a new 'ENGINE_cpy()' function that will produce a new ENGINE based
        copied from an original (except for the references, ie. the new copy will
        be like an ENGINE returned from 'ENGINE_new()' - a structural reference).
      
      * Removed the "null parameter" checking in the get/set functions - it is
        legitimate to set NULL values as a way of *changing* an ENGINE (ie.
        removing a handler that previously existed). Also, passing a NULL pointer
        for an ENGINE is obviously wrong for these functions, so don't bother
        checking for it. The result is a number of error codes and strings could
        be removed.
      d54bf145
  5. 20 2月, 2001 1 次提交
    • R
      Make all configuration macros available for application by making · cf1b7d96
      Richard Levitte 提交于
      sure they are available in opensslconf.h, by giving them names starting
      with "OPENSSL_" to avoid conflicts with other packages and by making
      sure e_os2.h will cover all platform-specific cases together with
      opensslconf.h.
      
      I've checked fairly well that nothing breaks with this (apart from
      external software that will adapt if they have used something like
      NO_KRB5), but I can't guarantee it completely, so a review of this
      change would be a good thing.
      cf1b7d96
  6. 15 12月, 2000 1 次提交
    • G
      This is an engine contributed by Broadcom - it is meant to support the · 016d7d25
      Geoff Thorpe 提交于
      BCM5805 and BCM5820 units. So far I've merely taken a skim over the code
      and changed a few things from their original contributed source
      (de-shadowing variables, removing variables from the header, and
      re-constifying some functions to remove warnings). If this gives
      compilation problems on any system, please let me know. We will hopefully
      know for sure whether this actually functions on a system with the relevant
      hardware in a day or two.  :-)
      016d7d25
  7. 07 11月, 2000 3 次提交
  8. 03 11月, 2000 1 次提交
    • R
      Change the engine library so the application writer has to explicitely · 11c0f120
      Richard Levitte 提交于
      load the "external" built-in engines (those that require DSO).  This
      makes linking with libdl or other dso libraries non-mandatory.
      
      Change 'openssl engine' accordingly.
      
      Change the engine header files so some declarations (that differed at
      that!) aren't duplicated, and make sure engine_int.h includes
      engine.h.  That way, there should be no way of missing the needed
      info.
      11c0f120
  9. 27 10月, 2000 1 次提交