Skip to content
  1. Mar 17, 2015
    • Matt Caswell's avatar
      Fix probable_prime over large shift · e4676e90
      Matt Caswell authored
      
      
      In the probable_prime() function we behave slightly different if the number
      of bits we are interested in is <= BN_BITS2 (the num of bits in a BN_ULONG).
      As part of the calculation we work out a size_limit as follows:
      
          size_limit = (((BN_ULONG)1) << bits) - BN_get_word(rnd) - 1;
      
      There is a problem though if bits == BN_BITS2. Shifting by that much causes
      undefined behaviour. I did some tests. On my system BN_BITS2 == 64. So I
      set bits to 64 and calculated the result of:
      
          (((BN_ULONG)1) << bits)
      
      I was expecting to get the result 0. I actually got 1! Strangely this...
      
          (((BN_ULONG)0) << BN_BITS2)
      
      ...does equal 0! This means that, on my system at least, size_limit will be
      off by 1 when bits == BN_BITS2.
      
      This commit fixes the behaviour so that we always get consistent results.
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      e4676e90
    • Matt Caswell's avatar
      Fix unintended sign extension · 3475c7a1
      Matt Caswell authored
      
      
      The function CRYPTO_128_unwrap_pad uses an 8 byte AIV (Alternative Initial
      Value). The least significant 4 bytes of this is placed into the local
      variable |ptext_len|. This is done as follows:
      
          ptext_len = (aiv[4] << 24) | (aiv[5] << 16) | (aiv[6] << 8) | aiv[7];
      
      aiv[4] is an unsigned char, but (aiv[4] << 24) is promoted to a *signed*
      int - therefore we could end up shifting into the sign bit and end up with
      a negative value. |ptext_len| is a size_t (typically 64-bits). If the
      result of the shifts is negative then the upper bits of |ptext_len| will
      all be 1.
      
      This commit fixes the issue by explicitly casting to an unsigned int.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      3475c7a1
    • Matt Caswell's avatar
      Fix seg fault in s_time · dfef52f6
      Matt Caswell authored
      
      
      Passing a negative value for the "-time" option to s_time results in a seg
      fault. This commit fixes it so that time has to be greater than 0.
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      dfef52f6
    • Matt Caswell's avatar
      Add sanity check to PRF · 668f6f08
      Matt Caswell authored
      
      
      The function tls1_PRF counts the number of digests in use and partitions
      security evenly between them. There always needs to be at least one digest
      in use, otherwise this is an internal error. Add a sanity check for this.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      668f6f08
    • Matt Caswell's avatar
      Fix memset call in stack.c · 7132ac83
      Matt Caswell authored
      
      
      The function sk_zero is supposed to zero the elements held within a stack.
      It uses memset to do this. However it calculates the size of each element
      as being sizeof(char **) instead of sizeof(char *). This probably doesn't
      make much practical difference in most cases, but isn't a portable
      assumption.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      7132ac83
    • Matt Caswell's avatar
      Move malloc fail checks closer to malloc · be1477ad
      Matt Caswell authored
      
      
      Move memory allocation failure checks closer to the site of the malloc in
      dgst app. Only a problem if the debug flag is set...but still should be
      fixed.
      
      Reviewed-by: default avatarTim Hudson <tjh@openssl.org>
      be1477ad
    • Matt Caswell's avatar
      Add malloc failure checks · a561bfe9
      Matt Caswell authored
      
      
      Add some missing checks for memory allocation failures in ca app.
      
      Reviewed-by: default avatarTim Hudson <tjh@openssl.org>
      a561bfe9
  2. 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
  3. Mar 15, 2015
  4. Mar 14, 2015
  5. Mar 13, 2015
  6. Mar 12, 2015