1. 19 Mar, 2003 1 commit
  2. 13 Mar, 2003 1 commit
  3. 11 Mar, 2003 1 commit
    • Geoff Thorpe's avatar
      The default implementation of DSA_METHOD has an interdependence on the · 879650b8
      Geoff Thorpe authored
      dsa_mod_exp() and bn_mod_exp() handlers from dsa_do_verify() and
      dsa_sign_setup(). When another DSA_METHOD implementation does not define
      these lower-level handlers, it becomes impossible to do a fallback to
      software on errors using a simple DSA_OpenSSL()->fn(key).
      
      This change allows the default DSA_METHOD to function in such circumstances
      by only using dsa_mod_exp() and bn_mod_exp() handlers if they exist,
      otherwise using BIGNUM implementations directly (which is what those
      handlers did before this change). There should be no noticable difference
      for the software case, or indeed any custom case that didn't already
      segfault, except perhaps that there is now one less level of indirection in
      all cases.
      
      PR: 507
      879650b8
  4. 28 Feb, 2003 1 commit
  5. 27 Feb, 2003 1 commit
  6. 25 Feb, 2003 1 commit
  7. 22 Feb, 2003 3 commits
  8. 19 Feb, 2003 1 commit
  9. 18 Feb, 2003 1 commit
  10. 15 Feb, 2003 1 commit
  11. 14 Feb, 2003 1 commit
  12. 13 Feb, 2003 1 commit
    • Richard Levitte's avatar
      Add full support for -rpath/-R, both in shared libraries and · 2d3de726
      Richard Levitte authored
      applications, at least on the platforms where it's known how
      to do it.
      
      Note: this has only been tested on GNU-based platforms (Linux), and
      needs to be tested on all others.  Additionally, it's not yet
      supported on the following platforms, for lack of information:
      
      Darwin (MacOS X)
      Cygwin
      OSF1/Alpha
      SVR3
      ReliantUNIX
      
      Please help out with testing and the platforms we don't yet know well
      enough.
      2d3de726
  13. 12 Feb, 2003 2 commits
  14. 11 Feb, 2003 1 commit
  15. 06 Feb, 2003 2 commits
  16. 05 Feb, 2003 1 commit
  17. 30 Jan, 2003 2 commits
  18. 24 Jan, 2003 2 commits
  19. 15 Jan, 2003 3 commits
  20. 13 Jan, 2003 2 commits
  21. 12 Jan, 2003 1 commit
  22. 10 Jan, 2003 1 commit
  23. 31 Dec, 2002 2 commits
  24. 30 Dec, 2002 1 commit
  25. 29 Dec, 2002 1 commit
  26. 19 Dec, 2002 1 commit
  27. 13 Dec, 2002 1 commit
  28. 12 Dec, 2002 1 commit
  29. 08 Dec, 2002 2 commits
    • Richard Levitte's avatar
      Since it's defined in draft-ietf-tls-compression-04.txt, let's make · fdaea9ed
      Richard Levitte authored
      ZLIB a known compression method, with the identity 1.
      fdaea9ed
    • Geoff Thorpe's avatar
      This is a first-cut at improving the callback mechanisms used in · e9224c71
      Geoff Thorpe authored
      key-generation and prime-checking functions. Rather than explicitly passing
      callback functions and caller-defined context data for the callbacks, a new
      structure BN_GENCB is defined that encapsulates this; a pointer to the
      structure is passed to all such functions instead.
      
      This wrapper structure allows the encapsulation of "old" and "new" style
      callbacks - "new" callbacks return a boolean result on the understanding
      that returning FALSE should terminate keygen/primality processing.  The
      BN_GENCB abstraction will allow future callback modifications without
      needing to break binary compatibility nor change the API function
      prototypes. The new API functions have been given names ending in "_ex" and
      the old functions are implemented as wrappers to the new ones.  The
      OPENSSL_NO_DEPRECATED symbol has been introduced so that, if defined,
      declaration of the older functions will be skipped. NB: Some
      openssl-internal code will stick with the older callbacks for now, so
      appropriate "#undef" logic will be put in place - this is in case the user
      is *building* openssl (rather than *including* its headers) with this
      symbol defined.
      
      There is another change in the new _ex functions; the key-generation
      functions do not return key structures but operate on structures passed by
      the caller, the return value is a boolean. This will allow for a smoother
      transition to having key-generation as "virtual function" in the various
      ***_METHOD tables.
      e9224c71