1. 28 9月, 2019 2 次提交
    • D
      Reorganize local header files · b5acbf91
      Dr. Matthias St. Pierre 提交于
      Apart from public and internal header files, there is a third type called
      local header files, which are located next to source files in the source
      directory. Currently, they have different suffixes like
      
        '*_lcl.h', '*_local.h', or '*_int.h'
      
      This commit changes the different suffixes to '*_local.h' uniformly.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/9681)
      b5acbf91
    • D
      Reorganize private crypto header files · 0c994d54
      Dr. Matthias St. Pierre 提交于
      Currently, there are two different directories which contain internal
      header files of libcrypto which are meant to be shared internally:
      
      While header files in 'include/internal' are intended to be shared
      between libcrypto and libssl, the files in 'crypto/include/internal'
      are intended to be shared inside libcrypto only.
      
      To make things complicated, the include search path is set up in such
      a way that the directive #include "internal/file.h" could refer to
      a file in either of these two directoroes. This makes it necessary
      in some cases to add a '_int.h' suffix to some files to resolve this
      ambiguity:
      
        #include "internal/file.h"      # located in 'include/internal'
        #include "internal/file_int.h"  # located in 'crypto/include/internal'
      
      This commit moves the private crypto headers from
      
        'crypto/include/internal'  to  'include/crypto'
      
      As a result, the include directives become unambiguous
      
        #include "internal/file.h"       # located in 'include/internal'
        #include "crypto/file.h"         # located in 'include/crypto'
      
      hence the superfluous '_int.h' suffixes can be stripped.
      
      The files 'store_int.h' and 'store.h' need to be treated specially;
      they are joined into a single file.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/9681)
      0c994d54
  2. 20 6月, 2018 1 次提交
  3. 31 5月, 2018 1 次提交
  4. 30 8月, 2017 2 次提交
  5. 20 7月, 2016 1 次提交
  6. 18 5月, 2016 1 次提交
  7. 09 3月, 2016 1 次提交
  8. 03 2月, 2016 1 次提交
  9. 07 5月, 2015 1 次提交
  10. 24 3月, 2015 1 次提交
  11. 22 1月, 2015 1 次提交
  12. 17 3月, 2008 1 次提交
  13. 22 11月, 2007 1 次提交
  14. 29 8月, 2006 1 次提交
  15. 05 6月, 2006 2 次提交
  16. 03 6月, 2006 2 次提交
  17. 01 6月, 2006 2 次提交
  18. 20 4月, 2004 1 次提交
  19. 14 12月, 2002 1 次提交
  20. 09 10月, 2001 1 次提交
  21. 26 9月, 2001 2 次提交
    • G
      This change adds cipher and digest support into ENGINE using the · b370230b
      Geoff Thorpe 提交于
      ENGING_TABLE mechanism. The necessary hooks from crypto/evp/ to use this
      will be committed shortly.
      b370230b
    • G
      This change replaces the ENGINE's underlying mechanics with the new · b6d1e52d
      Geoff Thorpe 提交于
      ENGINE_TABLE-based stuff - as described in crypto/engine/README.
      
      Associated miscellaneous changes;
       - the previous cipher/digest hooks that hardwired directly to EVP's
         OBJ_NAME-based storage have been backed out. New cipher/digest support
         has been constructed and will be committed shortly.
       - each implementation defines its own ENGINE_load_<name> function now.
       - the "openssl" ENGINE isn't needed or loaded any more.
       - core (not algorithm or class specific) ENGINE code has been split into
         multiple files to increase readability and decrease linker bloat.
       - ENGINE_cpy() has been removed as it wasn't really a good idea in the
         first place and now, because of registration issues, can't be
         meaningfully defined any more.
       - BN_MOD_EXP[_CRT] support is removed as per the README.
       - a bug in enginetest.c has been fixed.
      
      NB: This commit almost certainly breaks compilation until subsequent
      changes are committed.
      b6d1e52d
  22. 15 9月, 2001 1 次提交
  23. 07 9月, 2001 1 次提交
  24. 18 8月, 2001 2 次提交
  25. 12 7月, 2001 1 次提交
  26. 16 6月, 2000 1 次提交
    • G
      Currently the DSO_METHOD interface has one entry point to bind all · e9a68cfb
      Geoff Thorpe 提交于
      "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).
      e9a68cfb
  27. 20 4月, 2000 1 次提交
    • G
      This change facilitates name translation for shared libraries. The · b9e63915
      Geoff Thorpe 提交于
      technique used is far from perfect and alternatives are welcome.
      Basically if the translation flag is set, the string is not too
      long, and there appears to be no path information in the string,
      then it is converted to whatever the standard should be for the
      DSO_METHOD in question, eg;
          blah --> libblah.so   on *nix, and
          blah --> blah.dll     on win32.
      
      This change also introduces the DSO_ctrl() function that is used
      by the name translation stuff.
      b9e63915
  28. 05 4月, 2000 1 次提交
    • G
      This is a set of startup code for the DSO support, it's not yet linked into · 8f4fac7f
      Geoff Thorpe 提交于
      the build process (an upcoming commit no doubt), and is very much *new*
      code - what that means is that it compiles ok - usually. It certainly
      doesn't mean it runs well or even properly yet. Please don't muck round
      with this unless you're looking to help out and hunt bugs. :-)
      
      Currently this code doesn't have any support for controlling the "load"
      behaviour (eg. paths, filename translations, etc). That'll be handled
      using DSO_ctrl() and various flags, once we work out a sensible set of
      flags.
      8f4fac7f
  29. 18 1月, 2000 1 次提交
  30. 20 10月, 1999 1 次提交
  31. 22 6月, 1999 1 次提交
  32. 10 5月, 1999 1 次提交
  33. 24 4月, 1999 1 次提交