1. 20 3月, 2018 1 次提交
  2. 19 3月, 2018 2 次提交
  3. 16 3月, 2018 1 次提交
  4. 15 3月, 2018 5 次提交
  5. 02 3月, 2018 1 次提交
  6. 01 3月, 2018 1 次提交
  7. 28 2月, 2018 1 次提交
    • D
      bio_b64.c: prevent base64 filter BIO from decoding out-of-bound data · d070b4ae
      Dr. Matthias St. Pierre 提交于
      Fixes #5405, #1381
      
      The base64 filter BIO reads its input in chunks of B64_BLOCK_SIZE bytes.
      When processing input in PEM format it can happen in rare cases that
      
      - the trailing PEM marker crosses the boundary of a chunk, and
      - the beginning of the following chunk contains valid base64 encoded data.
      
      This happened in issue #5405, where the PEM marker was split into
      "-----END CER" and "TIFICATE-----" at the end of the first chunk.
      
      The decoding of the first chunk terminated correctly at the '-' character,
      which is treated as an EOF marker, and b64_read() returned. However,
      when called the second time, b64_read() read the next chunk and interpreted
      the string "TIFICATE" as valid base64 encoded data, adding 6 extra bytes
      '4c 81 48 08 04 c4'.
      
      This patch restores the assignment of the error code to 'ctx->cont', which
      was deleted accidentally in commit 5562cfac and which prevents b64_read()
      from reading additional data on subsequent calls.
      
      This issue was observed and reported by Annie Yousar.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5422)
      d070b4ae
  8. 27 2月, 2018 1 次提交
  9. 23 2月, 2018 1 次提交
  10. 14 2月, 2018 1 次提交
    • V
      Avoid fragile aliasing of SHA224/384 update/final · babab8e7
      Viktor Dukhovni 提交于
      This is purported to save a few cycles, but makes the code less
      obvious and more brittle, and in fact breaks on platforms where for
      ABI continuity reasons there is a SHA2 implementation in libc, and
      so EVP needs to call those to avoid conflicts.
      
      A sufficiently good optimizer could simply generate the same entry
      points for:
      
              foo(...) { ... }
          and
              bar(...) { return foo(...); }
      
      but, even without that, the different is negligible, with the
      "winner" varying from run to run (openssl speed -evp sha384):
      
          Old:
          type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes 16384 bytes
          sha384           28864.28k   117362.62k   266469.21k   483258.03k   635144.87k 649123.16k
      
          New:
          type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes 16384 bytes
          sha384           30055.18k   120725.98k   272057.26k   482847.40k   634585.09k 650308.27k
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      babab8e7
  11. 07 2月, 2018 2 次提交
  12. 24 1月, 2018 2 次提交
  13. 09 1月, 2018 1 次提交
  14. 08 1月, 2018 1 次提交
  15. 16 12月, 2017 1 次提交
  16. 10 12月, 2017 1 次提交
  17. 08 12月, 2017 1 次提交
  18. 20 11月, 2017 1 次提交
  19. 13 11月, 2017 1 次提交
  20. 06 11月, 2017 2 次提交
  21. 31 10月, 2017 3 次提交
  22. 18 10月, 2017 1 次提交
  23. 13 10月, 2017 1 次提交
  24. 12 10月, 2017 4 次提交
  25. 09 10月, 2017 1 次提交
  26. 15 9月, 2017 1 次提交
  27. 14 9月, 2017 1 次提交