1. 03 Feb, 2017 1 commit
  2. 04 Jan, 2017 1 commit
    • davidben's avatar
      Remove the password parameter for ECPrivateKey::ExportEncryptedPrivateKey. · 1c02c94c
      davidben authored
      Even with a password, the encryption scheme used here is really not what
      we'd want people to use. This does two things:
      
      1. Cut down on the number of ways to use ExportEncryptedPrivateKey and
         makes it less likely someone will mistakenly use it for security
         purposes.
      
      2. When we ported to BoringSSL, we added "raw" versions of
         PKCS8_{encrypt,decrypt} to account for confusion about two ways to
         encode the empty password. But PKCS8_{encrypt,decrypt} already
         handled this by treating NULL and "" differently. Limiting to just
         the empty password lets us trim BoringSSL's API surface in
         preparation for decoupling it from crypto/asn1.
      
      BUG=603319
      
      Review-Url: https://codereview.chromium.org/2608453002
      Cr-Commit-Position: refs/heads/master@{#441365}
      1c02c94c
  3. 28 Oct, 2016 1 commit
    • tfarina's avatar
      include boringssl headers from third_party explicitly · 29a3a174
      tfarina authored
      This also allow us to participate in DEPS checking, which will help
      catch instances of directories including BoringSSL without adding to
      build targets.
      
      This patch was partly generated by the following command lines:
      
      $ g grep -l -e '^#[[:blank:]]*include <\(openssl[^>]*\)>' | xargs sed -i
      '/^#[[:blank:]]*include/s/<\(openssl[^>]*\)>/"\1"/'
      $ g grep -l "#include \"openssl/" | xargs sed -i -e 's/\(#.*
      \)"\(openssl\/.*\)"/\1"third_party\/boringssl\/src\/include\/\2"/'
      
      The regex were taken from http://stackoverflow.com/a/25378698 and
      https://svn.boost.org/trac/boost/ticket/12057, and adapted to suit our
      needs.
      
      Then the includes were put in their right places with some manual editing and
      the help of tools/sort-headers.py.
      
      BUG=446558
      R=davidben@chromium.org,thestig@chromium.org,jochen@chromium.org,slan@chromium.org
      
      Review-Url: https://codereview.chromium.org/2449873005
      Cr-Commit-Position: refs/heads/master@{#428442}
      29a3a174
  4. 01 Oct, 2016 1 commit
  5. 13 Jul, 2016 1 commit
    • agl's avatar
      Switch to OpenSSL's |EVP_PKEY_up_ref| signature. · 5a7cadf1
      agl authored
      |EVP_PKEY_up_ref| was a BoringSSL addition to OpenSSL The next major,
      public OpenSSL release will include it, but it'll return 0/1 rather than
      the object being referenced.
      
      This change updates Chromium to expect that function signature (in a
      backwards compatible way). Once all callers have been updated likewise,
      BoringSSL will align this function with upstream OpenSSL.
      
      BUG=none
      
      Review-Url: https://codereview.chromium.org/2113143004
      Cr-Commit-Position: refs/heads/master@{#405192}
      5a7cadf1
  6. 28 Jun, 2016 1 commit
  7. 07 Jun, 2016 1 commit
  8. 21 Apr, 2016 1 commit
  9. 08 Apr, 2016 1 commit
  10. 01 Mar, 2016 1 commit
    • davidben's avatar
      Cut down on usage of deprecated APIs in //crypto. · 7dad2a3e
      davidben authored
      SSL_library_init is deprecated. It's CRYPTO_library_init. Switch from the
      legacy ASN.1 APIs to the new parsers where feasible.
      ECPrivateKey::CreateFromEncryptedPrivateKeyInfo is left alone for now as we
      still need a new version of those APIs.
      
      This also adds a scoper for CBB for use in later CLs.
      
      BUG=499653
      
      Review URL: https://codereview.chromium.org/1739403002
      
      Cr-Commit-Position: refs/heads/master@{#378610}
      7dad2a3e
  11. 21 Dec, 2015 1 commit
  12. 15 Oct, 2015 1 commit
  13. 02 Sep, 2015 1 commit
  14. 13 May, 2015 1 commit
  15. 12 May, 2015 1 commit
  16. 21 Feb, 2015 1 commit
  17. 06 Aug, 2014 1 commit
  18. 10 Jul, 2014 1 commit
    • rsleevi@chromium.org's avatar
      Eliminate ScopedOpenSSL in favour of scoped_ptr<> specializations. · cd9b75b1
      rsleevi@chromium.org authored
      Match the NSS, CryptoAPI (Win) and Security (OS X) approaches by
      declaring the scoped types as specializations of our existing scoped
      classes.
      
      Like NSS, this requires an intermediate helper type, because our
      scoped_ptr<> doesn't accept deleter functions as template
      arguments (though they are valid in C++11's unique_ptr<>). A few base
      cryptographic (non-certificate) types are used in
      scoped_openssl_types.h, while the remainder are left for
      implementations to specialize as needed.
      
      In an ideal world, this would be scoped_ptr<FOO, FOO_free>, but that
      will require unique_ptr<> support.
      
      BUG=388904
      
      Review URL: https://codereview.chromium.org/361193003
      
      git-svn-id: svn://svn.chromium.org/chrome/trunk/src@282257 0039d316-1c4b-4281-b951-d872f2087c98
      cd9b75b1
  19. 24 Jun, 2014 1 commit
  20. 22 Mar, 2014 1 commit
  21. 13 Nov, 2013 1 commit
  22. 17 Oct, 2013 1 commit
  23. 09 Jul, 2012 1 commit
  24. 09 Nov, 2011 1 commit