Skip to content
  1. Jan 22, 2016
  2. Jan 21, 2016
    • Richard Levitte's avatar
      Refactor config - @MK1MF_Builds out, general build scheme in · 88087414
      Richard Levitte authored
      
      
      Time to get rid of @MK1MF_Builds and introduce a more flexible
      'build_scheme' configuration key.  Its value may be a string or an
      array of strings, meaning we need to teach resolve_config how to
      handle ARRAY referenses.
      
      The build scheme is a word that selects a function to create the
      appropriate result files for a certain configuration.  Currently valid
      build schemes aer "mk1mf" and "unixmake", the plan is however to add
      at least one other for a more universal build scheme.
      
      Incidently, this also adds the functions 'add' and 'add_before', which
      can be used in a configuration, so instead of having to repeatedly
      write a sub like this:
      
      	key1 => sub { join(" ", @_, "myvalues"); },
      	key2 => sub { join(" ", "myvalues", @_); },
      
      one could write this:
      
      	key1 => add(" ", "myvalues"),
      	key2 => add_before(" ", "myvalues"),
      
      The good point with 'add' and 'add_before' is that they handle
      inheritances where the values are a misture of scalars and ARRAYs.  If
      there are any ARRAY to be found, the resulting value will be an ARRAY,
      otherwise it will be a scalar with all the incoming valued joined
      together with the separator given as first argument to add/add_before.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      88087414
    • Richard Levitte's avatar
      Refactor config - move templates and template docs to Configurations · 9e0724a1
      Richard Levitte authored
      
      
      Move the documentation of the target configuration form to
      Configurations/README.
      
      Move initial assembler object templates to
      Configurations/00-BASE-templates.conf.
      
      Furthermore, remove all variables containing the names of the
      non-assembler object files and make a BASE template of them instead.
      The  values from this templates are used as defaults as is.  The
      remaining manipulation of data when assembler modules are used is done
      only when $no_asm is false.
      
      While doing this, clean out some other related variables that aren't
      used anywhere.
      
      Also, we had to move the resolution of the chosen target a bit, or the
      function 'asm' would never catch a true $no_asm...  this hasn't
      mattered before we've moved it all to the BASE template, but now it
      does.
      
      At the same time, add the default for the 'unistd' key to the BASE
      template.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      9e0724a1
    • Richard Levitte's avatar
      Refresh the thinking of --prefix and --openssldir · d74dfafd
      Richard Levitte authored
      
      
      --prefix is now exclusively used for software and manual installation.
      --openssldir is not exclusively used as a default location for certs,
      keys and the default openssl.cnf.
      
      This change is made to bring clarity, to have the two less
      intertwined, and to be more compatible with the usual ways of software
      installation.
      
      Please change your habits and scripts to use --prefix rather than
      --openssldir for installation location now.
      
      Reviewed-by: default avatarViktor Dukhovni <viktor@openssl.org>
      d74dfafd
    • Billy Brumley's avatar
      dd67493c
    • Richard Levitte's avatar
    • Richard Levitte's avatar
      Refactor config - consolidate handling of disabled stuff · c569e206
      Richard Levitte authored
      
      
      It's time to refactor the handling of %disabled so that all
      information of value is in the same place.  We have so far had a few
      cascading disable rules in form of code, far away from %disabled.
      Instead, bring that information to the array @disable_cascade, which
      is a list of pairs of the form 'test => descendents'.  The test part
      can be a string, and it's simply checked if that string is a key in
      %disabled, or it can be a CODEref to do a more complex test.  If the
      test comes true, then all descendents are disabled.  This check is
      performed until there are no more things that need to be disabled.
      
      Also, $default_depflags is constructed from the information in
      %disabled instead of being a separate string.  While a string of its
      own is visually appealing, it's much too easy to forget to update it
      when something is changed in %disabled.
      
      Reviewed-by: default avatarViktor Dukhovni <viktor@openssl.org>
      c569e206
    • Richard Levitte's avatar
      Refactor config - rewrite handling of "reconf" · fe05264e
      Richard Levitte authored
      
      
      The way the "reconf"/"reconfigure" argument is handled is overly
      complicated.  Just grep for it first, and if it is there in the
      current arguments, get the old command line arguments from Makefile.
      
      While we're at it, make the Makefile variable CONFIGURE_ARGS hold the
      value as a perl list of strings.  This makes things much safer in case
      one of the arguments would contain a space.  Since CONFIGURE_ARGS is
      used for nothing else, there's no harm in this.
      
      Reviewed-by: default avatarViktor Dukhovni <viktor@openssl.org>
      fe05264e
    • Viktor Dukhovni's avatar
      Multiple -trusted/-untrusted/-CRLfile options in verify · feb2f53e
      Viktor Dukhovni authored
      
      
      It is sometimes useful (especially in automated tests) to supply
      multiple trusted or untrusted certificates via separate files rather
      than have to prepare a single file containing them all.
      
      To that end, change verify(1) to accept these options zero or more
      times.  Also automatically set -no-CAfile and -no-CApath when
      -trusted is specified.
      
      Improve verify(1) documentation, which could still use some work.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      feb2f53e
    • Viktor Dukhovni's avatar
    • Viktor Dukhovni's avatar
      More X509_verify_cert() tests via verify(1). · 6e8beabc
      Viktor Dukhovni authored
      
      
      Still need tests for trusted-first and tests that probe construction
      of alternate chains.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      6e8beabc
    • Viktor Dukhovni's avatar
      Reject when explicit trust EKU are set and none match. · 3342dcea
      Viktor Dukhovni authored
      
      
      Returning untrusted is enough for for full chains that end in
      self-signed roots, because when explicit trust is specified it
      suppresses the default blanket trust of self-signed objects.
      
      But for partial chains, this is not enough, because absent a similar
      trust-self-signed policy, non matching EKUs are indistinguishable
      from lack of EKU constraints.
      
      Therefore, failure to match any trusted purpose must trigger an
      explicit reject.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      3342dcea
    • Viktor Dukhovni's avatar
      Commit pre-generated test_verify certs · 3d6e91c6
      Viktor Dukhovni authored
      
      
      These can be re-generated via:
      
              cd test/certs; ./setup.sh
      
      if need be.  The keys are all RSA 2048-bit keys, but it is possible
      to change that via environment variables.
      
          cd test/certs
          rm -f *-key.pem *-key2.pem
          OPENSSL_KEYALG=rsa OPENSSL_KEYBITS=3072 ./setup.sh
      
          cd test/certs
          rm -f *-key.pem *-key2.pem
          OPENSSL_KEYALG=ecdsa OPENSSL_KEYBITS=secp384r1 ./setup.sh
      
          ...
      
      Keys are re-used if already present, so the environment variables
      are only used when generating any keys that are missing.  Hence
      the "rm -f"
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      3d6e91c6
    • Viktor Dukhovni's avatar
      84783517
  3. Jan 20, 2016
  4. Jan 19, 2016