1. 02 8月, 2016 2 次提交
  2. 31 7月, 2016 1 次提交
  3. 20 7月, 2016 1 次提交
  4. 19 7月, 2016 2 次提交
  5. 15 7月, 2016 2 次提交
  6. 08 7月, 2016 1 次提交
  7. 07 7月, 2016 1 次提交
    • R
      Versioning engines default location: the Unix case · b2de11c5
      Richard Levitte 提交于
      OpenSSL engines are tied to the OpenSSL shared library versions,
      starting with OpenSSL 1.1.  We therefore need to install them in
      directories which have the shared library version in it's name, to
      easily allow multiple OpenSSL versions to be installed at the same
      time.
      
      For Unix, the default installation directory is changed from
      $PREFIX/lib/engines to $PREFIX/lib/engines-${major}_${minor} (mingw)
      or $PREFIX/lib/engines-${major}.${minor} (all but mingw)
      
      ($PREFIX is the directory given for the configuration option --prefix,
      and ${major} and ${minor} are the major and minor shared library
      version numbers)
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      b2de11c5
  8. 06 7月, 2016 1 次提交
  9. 02 7月, 2016 2 次提交
  10. 28 6月, 2016 3 次提交
  11. 17 6月, 2016 1 次提交
    • R
      Harmonise the different build files · 4813ad2d
      Richard Levitte 提交于
      - User targets are now the same and generally do the same things
      - configdata.pm depends on exactly the same files on all platforms
      - VMS production of shared libraries is simplified
      - VMS automatic dependency files get the extension .D rather than .MMS
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      4813ad2d
  12. 15 6月, 2016 2 次提交
  13. 10 6月, 2016 1 次提交
  14. 05 6月, 2016 1 次提交
    • R
      Add developer targets for each subdirectory we have something to build in · 0ad1d94d
      Richard Levitte 提交于
      Previous build scheme allowed building just the stuff in one
      subdirectory, like this:
      
          make -C crypto/aes
      
      Because the unified only has a top-level Makefile, this is not
      possible with it.  This change adds a replacement where each directory
      we have something to build in becomes a target in its own right,
      allowing building something like this:
      
          make crypto/aes
      
      The exception is the directory test, because we already have such a
      target.
      Reviewed-by: NStephen Henson <steve@openssl.org>
      0ad1d94d
  15. 01 6月, 2016 1 次提交
  16. 27 5月, 2016 1 次提交
    • R
      Allow space in PERL spec (unix only) · cbece220
      Richard Levitte 提交于
      Someone wants to configure like this:
      
          PERL="/usr/bin/env perl" ./config
      
      The end goal is to get that in the #! line of CA.pl and a few other
      scripts.  That works well already, but in the Makefile, there were a
      few lines looking like this:
      
          PERL=$(PERL) $(PERL) whatever.pl ...
      
      Those need some quoting.
      
      RT#4311
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      cbece220
  17. 25 5月, 2016 1 次提交
  18. 23 5月, 2016 1 次提交
  19. 17 5月, 2016 1 次提交
  20. 16 5月, 2016 1 次提交
  21. 04 5月, 2016 1 次提交
  22. 02 5月, 2016 1 次提交
  23. 01 5月, 2016 1 次提交
  24. 29 4月, 2016 1 次提交
  25. 26 4月, 2016 1 次提交
    • R
      Build system: add include directories and dependencies for generators · 8d34daf0
      Richard Levitte 提交于
      In the case of generating a file like this:
      
          GENERATE[foo.S]=mkfoo.pl arg1 arg2
      
      the 'mkfoo.pl' generator itself might need to include other files,
      such as perl modules within our source tree.  We can reuse already
      existing syntax for it, like this:
      
          INCLUDE[mkfoo.pl]=module/path
      
      or:
      
          DEPEND[mkfoo.pl]=modules/mymodule.pm
      
      This change implements the support for such constructs, and for the
      DEPEND statement, for any value that indicates a perl module (.pm
      file), it will automatically infer an INCLUDE statement for its
      directory, just like it does for C header files, so you won't have do
      write this:
      
          DEPEND[mkfoo.pl]=modules/mymodule.pm
          INCLUDE[mkfoo.pl]=modules
      Reviewed-by: NEmilia Käsper <emilia@openssl.org>
      8d34daf0
  26. 20 4月, 2016 1 次提交
  27. 14 4月, 2016 2 次提交
  28. 13 4月, 2016 1 次提交
  29. 07 4月, 2016 1 次提交
  30. 05 4月, 2016 1 次提交
    • E
      New SSL test framework · 453dfd8d
      Emilia Kasper 提交于
      Currently, SSL tests are configured via command-line switches to
      ssltest.c. This results in a lot of duplication between ssltest.c and
      apps, and a complex setup. ssltest.c is also simply old and needs
      maintenance.
      
      Instead, we already have a way to configure SSL servers and clients, so
      we leverage that. SSL tests can now be configured from a configuration
      file. Test servers and clients are configured using the standard
      ssl_conf module. Additional test settings are configured via a test
      configuration.
      
      Moreover, since the CONF language involves unnecessary boilerplate, the
      test conf itself is generated from a shorter Perl syntax.
      
      The generated testcase files are checked in to the repo to make
      it easier to verify that the intended test cases are in fact run; and to
      simplify debugging failures.
      
      To demonstrate the approach, min/max protocol tests are converted to the
      new format. This change also fixes MinProtocol and MaxProtocol
      handling. It was previously requested that an SSL_CTX have both the
      server and client flags set for these commands; this clearly can never work.
      
      Guide to this PR:
       - test/ssl_test.c - test framework
       - test/ssl_test_ctx.* - test configuration structure
       - test/handshake_helper.* - new SSL test handshaking code
       - test/ssl-tests/ - test configurations
       - test/generate_ssl_tests.pl - script for generating CONF-style test
         configurations from perl inputs
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      453dfd8d
  31. 04 4月, 2016 1 次提交
  32. 03 4月, 2016 1 次提交