1. 22 Dec, 2021 5 commits
  2. 16 Dec, 2021 6 commits
  3. 15 Dec, 2021 2 commits
    • David Benjamin's avatar
      Fix the easy -Wformat-signedness errors. · 4f1fae30
      David Benjamin authored
      GCC has a warning that complains about even more type mismatches in
      printf. Some of these are a bit messy and will be fixed in separate CLs.
      This covers the easy ones.
      The .*s stuff is unfortunate, but printf has no size_t-clean string
      printer. ALPN protocol lengths are bound by uint8_t, so it doesn't
      really matter.
      The IPv6 printing one is obnoxious and arguably a false positive. It's
      really a C language flaw: all types smaller than int get converted to
      int when you do arithmetic. So something like this first doesn't
      overflow the shift because it computes over int, but then the result
      overall is stored as an int.
        uint8_t a, b;
        (a << 8) | b
      On the one hand, this fixes a "missing" cast to uint16_t before the
      shift. At the same time, the incorrect final type means passing it to
      %x, which expects unsigned int. The compiler has forgotten this value
      actually fits in uint16_t and flags a warning. Mitigate this by storing
      in a uint16_t first.
      The story doesn't quite end here. Arguments passed to variadic functions
      go through integer promotion[0], so the argument is still passed to
      snprintf as an int! But then va_arg allows for a signedness mismatch[1],
      provided the value is representable in both types. The combination means
      that %x, though actually paired with unsigned, also accept uint8_t and
      uint16_t, because those are guaranteed to promote to an int that meets
      [1]. GCC recognizes [1] applies here.
      (There's also PRI16x, but that's a bit tedious to use and, in glibc, is
      defined as plain "x" anyway.)
      [0] https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions
      [1] https://en.cppreference.com/w/c/variadic/va_arg
      Bug: 450
      Change-Id: Ic1d41356755a18ab922956dd2e07b560470341f4
      Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50765
      Reviewed-by: default avatarAdam Langley <agl@google.com>
      Commit-Queue: Adam Langley <agl@google.com>
    • David Benjamin's avatar
      Add BIO_tell and BIO_seek wrappers. · e21f272a
      David Benjamin authored
      Change-Id: Ia5db220d13cf42fac6958a2c7416743ca2991479
      Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50745
      Reviewed-by: default avatarAdam Langley <agl@google.com>
      Commit-Queue: David Benjamin <davidben@google.com>
  4. 14 Dec, 2021 2 commits
  5. 13 Dec, 2021 1 commit
  6. 08 Dec, 2021 1 commit
  7. 07 Dec, 2021 2 commits
  8. 30 Nov, 2021 2 commits
  9. 29 Nov, 2021 1 commit
  10. 22 Nov, 2021 1 commit
  11. 20 Nov, 2021 1 commit
  12. 18 Nov, 2021 3 commits
    • David Benjamin's avatar
      Add SSL_has_pending. · b3ed071e
      David Benjamin authored
      This was added in OpenSSL 1.1.x. It is slightly different from
      SSL_pending in that it also reports buffered transport data.
      Change-Id: I81e217aad1ceb6f4c31c36634a546e12b6dc8dfc
      Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50445
      Commit-Queue: David Benjamin <davidben@google.com>
      Reviewed-by: default avatarAdam Langley <agl@google.com>
    • David Benjamin's avatar
      Update HPKE test vectors. · ea57bcbd
      David Benjamin authored
      HPKE draft-12 has no changes from draft-08 except that the test vectors
      were refreshed and some fields in the JSON file renamed. Also fix the
      test vector reference to point to copy from the spec rather than the
      (identical) copy from the reference implementation.
      Change-Id: Icd4fd467672cc8701fcd2b262ac90c5adc05ac39
      Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50465
      Reviewed-by: default avatarAdam Langley <agl@google.com>
    • David Benjamin's avatar
      Add various OpenSSL compatibility functions. · 16a94930
      David Benjamin authored
      The non-_ex EVP_CIPHER_CTX Final functions are a bit interesting. Unlike
      EVP_DigestFinal(_ex), where the non-_ex version calls EVP_MD_CTX_cleanup
      for you, the EVP_CIPHER_CTX ones do not automatically cleanup.
      EVP_CipherFinal and EVP_CipherFinal_ex are identical in all releases
      where they exist.
      This appears to date to OpenSSL 0.9.7:
      Prior to OpenSSL 0.9.7, EVP_MD_CTX and EVP_CIPHER_CTX did not use void*
      data fields. Instead, they just had a union of context structures for
      every algorithm OpenSSL implemented.
      EVP_MD_CTX was truly cleanup-less. There were no EVP_MD_CTX_init or
      EVP_MD_CTX_cleanup functions at all. EVP_DigestInit filled things in
      without reference to the previous state. EVP_DigestFinal didn't cleanup
      because there was nothing to cleanup.
      EVP_CIPHER_CTX was also a union, but for some reason did include
      EVP_CIPHER_CTX_init and EVP_CIPHER_CTX_cleanup. EVP_CIPHER_CTX_init
      seemed to be optional: EVP_CipherInit with non-NULL EVP_CIPHER similarly
      didn't reference the previous state. EVP_CipherFinal did not call
      EVP_CIPHER_CTX_cleanup, but EVP_CIPHER_CTX_cleanup didn't do anything.
      It called an optional cleanup hook on the EVP_CIPHER, but as far as I
      can tell, no EVP_CIPHER implemented it.
      Then OpenSSL 0.9.7 introduced ENGINE. The union didn't work anymore, so
      EVP_MD_CTX and EVP_CIPHER_CTX contained void* with allocated
      type-specific data. The introduced EVP_MD_CTX_init and
      EVP_MD_CTX_cleanup. For (imperfect!) backwards compatibility,
      EVP_DigestInit and EVP_DigestFinal transparently called init/cleanup for
      you. EVP_DigestInit_ex and EVP_DigestFinal_ex became the more flexible
      versions that left init/cleanup to the caller.
      EVP_CIPHER_CTX got the same treatment with
      EVP_CipherInit/EVP_CipherInit_ex, but *not*
      EVP_CipherFinal/EVP_CipherFinal_ex. The latter did the same thing. The
      history seems to be that 581f1c84940d77451c2592e9fa470893f6c3c3eb
      introduced the Final/Final_ex split, with the former doing an
      auto-cleanup, then 544a2aea4ba1fad76f0802fb70d92a5a8e6ad85a undid it.
      Looks like the motivation is that EVP_CIPHER_CTX objects are often
      reused to do multiple operations with a single key. But they missed that
      the split functions are now unnecessary.
      Amusingly, OpenSSL's documentation incorrectly said that EVP_CipherFinal
      cleaned up after the call until it was fixed in
      538860a3ce0b9fd142a7f1a62e597cccb74475d3. The fix says that some
      releases cleaned up, but there were, as far as I can tell, no actual
      releases with that behavior.
      I've put the new Final functions in the deprecated section, purely
      because there is no sense in recommending two different versions of the
      same function to users, and Final_ex seems to be more popular. But there
      isn't actually anything wrong with plain Final.
      Change-Id: Ic2bfda48fdcf30f292141add8c5f745348036852
      Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50485
      Reviewed-by: default avatarAdam Langley <agl@google.com>
  13. 15 Nov, 2021 1 commit
  14. 04 Nov, 2021 3 commits
  15. 01 Nov, 2021 7 commits
  16. 30 Oct, 2021 1 commit
  17. 27 Oct, 2021 1 commit