Skip to content
  1. Mar 16, 2015
    • Richard Levitte's avatar
      Do not keep TABLE in version control. · e3c15964
      Richard Levitte authored
      
      
      TABLE was always a debugging tool, and permitted everyone to see the
      effect of changes in the string-format configs.  The hash-format
      configs being much more readable, distributing TABLE becomes much less
      necessary.
      
      Being able to produce a TABLE is kept, however, as it still is a
      useful debugging tool for configs, what with multi-level inheritance
      and all.
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      e3c15964
    • Richard Levitte's avatar
      Configuration cleanup: personal configs · a5250ec0
      Richard Levitte authored
      
      
      Move obviously personal configurations to personal files.
      
      Note: those files should really not be in the main repo at all
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      a5250ec0
    • Richard Levitte's avatar
      Updated TABLE · d52dcf8d
      Richard Levitte authored
      
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      d52dcf8d
    • Richard Levitte's avatar
    • Richard Levitte's avatar
      Change all the main configurations to the new format. · 5e1b2353
      Richard Levitte authored
      
      
      As part of this, remove some levitte examples that never were relevant.
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      5e1b2353
    • Richard Levitte's avatar
      Rethink templates. · b1245529
      Richard Levitte authored
      
      
      Because base templates express inheritance of values, the attribute is
      renamed to 'inherit_from', and texts about this talk about 'inheritance(s)'
      rather than base templates.
      
      As they were previously implemented, base templates that were listed
      together would override one another, the first one acting as defaults for
      the next and so on.
      
      However, it was pointed out that a strength of inheritance would be to
      base configurations on several templates - for example one for CPU, one
      for operating system and one for compiler - and that requires a different
      way of combining those templates.  With this change, inherited values
      from several inheritances are concatenated by default (keep on reading).
      
      Also, in-string templates with the double-curly syntax are removed,
      replaced with the possibility to have a configuration value be a coderef
      (i.e. a 'sub { /* your code goes here */ }') that gets the list of values
      from all inheritances as the list @_.  The result of executing such a
      coderef on a list of values is assumed to become a string.  ANY OTHER
      FORM OF VALUE WILL CURRENTLY BREAK.
      
      As a matter of fact, an attribute in the current config with no value is
      assumed to have this coderef as value:
      
          sub { join(' ', @_) }
      
      While we're at it, rename debug-[cl]flags to debug_[cl]flags and
      nodebug-[cl]flags to release_[cl]flags.
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      b1245529
    • Richard Levitte's avatar
    • Richard Levitte's avatar
      Add base template processing. · 7d46b942
      Richard Levitte authored
      
      
      Base templates are templates that are used to inherit from.  They can
      loosely be compared with parent class inheritance in object orientation.
      They can be used for the same purpose as the variables with multi-field
      strings are used in old-style string configurations.
      
      Base templates are declared with the base_templates configuration
      attribute, like so:
      
      	"example_target" => {
      		base_templates => [ "x86_asm", ... ]
      		...
      	}
      
      Note: The value of base_templates MUST be an array reference (an array
      enclosed in square brackets).
      
      Any configuration target can be used as a base template by another.  It
      is also possible to have a target that's a pure template and not meant to
      be used directly as a configuration target.  Such a target is marked with
      the template configuration attribute, like so:
      
      	"example_template" => {
      		template => 1,
      		cc => "mycc",
      		...
      	},
      
      As part of this commit, all variables with multi-field strings have been
      translated to pure templates.  The variables currently remain since we
      can't expect people to shift to hash table configurations immediately.
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      7d46b942
    • Richard Levitte's avatar
      Add template reference processing. · 09816a2e
      Richard Levitte authored
      
      
      Template references are words with double brackets, and refer to the
      same field in the target pointed at the the double bracketed word.
      
      For example, if a target's configuration has the following entry:
      
          'cflags' => '-DFOO {{x86_debug}}'
      
      ... then {{x86_debug}} will be replaced with the 'cflags' value from
      target 'x86_debug'.
      
      Note: template references are resolved recursively, and circular
      references are not allowed
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      09816a2e
    • Richard Levitte's avatar
      Rewrite Configure to handle the target values as hash tables. · aaf878cc
      Richard Levitte authored
      
      
      The reasoning is that configuration strings are hard to read and error
      prone, and that a better way would be for them to be key => value hashes.
      
      Configure is made to be able to handle target configuration values as a
      string as well as a hash.  It also does the best it can to combine a
      "debug-foo" target with a "foo" target, given that they are similar
      except for the cflags and lflags values.  The latter are spliced into
      options that are common for "debug-foo" and "foo", options that exist
      only with "debug-foo" and options that exist only with "foo", and make
      them into combinable attributes that holds common cflags, extra cflags
      for debuggin and extra cflags for non-debugging configurations.
      
      The next step is to make it possible to have template configurations.
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      aaf878cc
    • Dr. Stephen Henson's avatar
      Make X509_ATTRIBUTE opaque. · 9b0a4531
      Dr. Stephen Henson authored
      
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      9b0a4531
  2. Mar 15, 2015
  3. Mar 14, 2015
  4. Mar 13, 2015
  5. Mar 12, 2015
  6. Mar 11, 2015
  7. Mar 10, 2015
    • Emilia Kasper's avatar
      Harmonize return values in dtls1_buffer_record · 06c6a2b4
      Emilia Kasper authored
      
      
      Ensure all malloc failures return -1.
      
      Reported by Adam Langley (Google).
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      06c6a2b4
    • Richard Godbee's avatar
      BIO_debug_callback: Fix output on 64-bit machines · 460e920d
      Richard Godbee authored
      
      
      BIO_debug_callback() no longer assumes the hexadecimal representation of
      a pointer fits in 8 characters.
      
      Signed-off-by: default avatarRichard Levitte <levitte@openssl.org>
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      460e920d
    • Matt Caswell's avatar
      Prevent handshake with unseeded PRNG · e1b568dd
      Matt Caswell authored
      
      
      Fix security issue where under certain conditions a client can complete a
      handshake with an unseeded PRNG. The conditions are:
      - Client is on a platform where the PRNG has not been seeded, and the
      user has not seeded manually
      - A protocol specific client method version has been used (i.e. not
      SSL_client_methodv23)
      - A ciphersuite is used that does not require additional random data
      from the PRNG beyond the initial ClientHello client random
      (e.g. PSK-RC4-SHA)
      
      If the handshake succeeds then the client random that has been used will
      have been generated from a PRNG with insufficient entropy and therefore
      the output may be predictable.
      
      For example using the following command with an unseeded openssl will
      succeed on an unpatched platform:
      
      openssl s_client -psk 1a2b3c4d -tls1_2 -cipher PSK-RC4-SHA
      
      CVE-2015-0285
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      e1b568dd