One ASN1_R_UNKNOWN_FORMAT got mispelled into ASN1_R_UNKOWN_FORMAT and
duplicated.
Change-Id: If123ef848ffe68afa021f5f3e3fb08eac92c5f94
Reviewed-on: https://boringssl-review.googlesource.com/1911
Reviewed-by: Adam Langley <agl@google.com>
Not that these functions can actually fail. The only codepaths that do so are
user errors.
Change-Id: I9fcbd402ab6574b5423ae22b462a0e1192ef01d7
Reviewed-on: https://boringssl-review.googlesource.com/1900
Reviewed-by: Adam Langley <agl@google.com>
This resolves a pile of MSVC warnings in Chromium.
Change-Id: Ib9a29cb88d8ed8ec4118d153260f775be059a803
Reviewed-on: https://boringssl-review.googlesource.com/1865
Reviewed-by: Adam Langley <agl@google.com>
Chromium does not like static initializers, and the CPU logic uses one to
initialize CPU bits. However, the crypto library lacks an explicit
initialization function, which could complicate (no compile-time errors)
porting existing code which uses crypto/, but not ssl/.
Add an explicit CRYPTO_library_init function, but make it a no-op by default.
It only does anything (and is required) if building with
BORINGSSL_NO_STATIC_INITIALIZER.
Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39
Reviewed-on: https://boringssl-review.googlesource.com/1770
Reviewed-by: Adam Langley <agl@google.com>
Get all this stuff out of the way.
- OPENSSL_NO_MD5
- OPENSSL_NO_SHA
- OPENSSL_NO_EC
- OPENSSL_NO_ECDSA
- OPENSSL_NO_ECDH
- OPENSSL_NO_NEXTPROTONEG
- OPENSSL_NO_DH
- OPENSSL_NO_SSL3
- OPENSSL_NO_RC4
- OPENSSL_NO_RSA
Also manually removed a couple instances of OPENSSL_NO_DSA that seemed to be
confused anyway. Did some minor manual cleanup. (Removed a few now-pointless
'if (0)'s.)
Change-Id: Id540ba97ee22ff2309ab20ceb24c7eabe766d4c4
Reviewed-on: https://boringssl-review.googlesource.com/1662
Reviewed-by: Adam Langley <agl@google.com>
This change removes the previous OpenSSL/NSS hack in PKCS#12 parsing and
limits the hacks purely to the BER->DER conversion function, where they
belong.
PKCS#7 and #12 switch between implicit and explicit tags in different
places and sometimes only implicitly define that they are using implicit
tags. This change fixes a previous confusion where an implicit tag was
thought to be explicit.
Change-Id: Ib68c78cf2a1bfcbf90a296cb98313ab86ed2a1f3
Reviewed-on: https://boringssl-review.googlesource.com/1640
Reviewed-by: Adam Langley <agl@google.com>
This fixes several of the problems with the old API.
- Padding was completely ignored.
- ='s in the middle of the input were accepted.
- It tries to be helpful and strips leading/trailing whitespace.
Change-Id: I99b9d5e6583f7eaf9bf0b6ee9ca39799811b58dc
Reviewed-on: https://boringssl-review.googlesource.com/1602
Reviewed-by: Adam Langley <agl@google.com>
Previously, the ASN.1 functions in bytestring were capable of processing
indefinite length elements when the _ber functions were used. That works
well enough for PKCS#3, but NSS goes a bit crazy with BER encoding and
PKCS#12. Rather than complicate the core bytestring functions further,
the BER support is removed from them and moved to a separate function
that converts from BER to DER (if needed).
Change-Id: I2212b28e99bab9fab8c61f80d2012d3e5a3cc2f0
Reviewed-on: https://boringssl-review.googlesource.com/1591
Reviewed-by: Adam Langley <agl@google.com>
Otherwise, in C, it becomes a K&R function declaration which doesn't actually
type-check the number of arguments.
Change-Id: I0731a9fefca46fb1c266bfb1c33d464cf451a22e
Reviewed-on: https://boringssl-review.googlesource.com/1582
Reviewed-by: Adam Langley <agl@google.com>
Several callers of EVP_EncodeBlock are doing ad-hoc versions of this
function without any overflow checks.
Change-Id: I4d0cad2347ea8c44b42465e8b14b2783db69ee8f
Reviewed-on: https://boringssl-review.googlesource.com/1511
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This function serialises a PKCS#7 structure containing a number of
certificates.
Change-Id: Iaf15887e1060d5d201d5a3dd3dca8d51105ee6d6
Reviewed-on: https://boringssl-review.googlesource.com/1431
Reviewed-by: Adam Langley <agl@google.com>
Avoid needing to manually increment the reference count and using the right
lock, both here and in Chromium.
Change-Id: If116ebc224cfb1c4711f7e2c06f1fd2c97af21dd
Reviewed-on: https://boringssl-review.googlesource.com/1415
Reviewed-by: Adam Langley <agl@google.com>
Reference counting should be internal to the type, otherwise callers need to
know which lock to use.
Change-Id: If4d805876a321ef6dece115c805e605584ff311e
Reviewed-on: https://boringssl-review.googlesource.com/1414
Reviewed-by: Adam Langley <agl@google.com>
Caught by clang scan-build. (The allocation was larger than it should have
been.)
Change-Id: Ideb800118f65aaba1ee85b7611c8a705671025a8
Reviewed-on: https://boringssl-review.googlesource.com/1340
Reviewed-by: Adam Langley <agl@google.com>
When I switched the base64 code to use size_t, I missed that one of the
loops was counting down, not up, and depended on the loop variable going
negative.
Additionally this change fixes a bug in NETSCAPE_SPKI_b64_encode where
the size of the result buffer was incorrectly calculated and a possible
memory leak.
Change-Id: Ibdf644244291274f50b314f3bb13a61b46858ca1
Reviewed-on: https://boringssl-review.googlesource.com/1220
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Previously, public headers lived next to the respective code and there
were symlinks from include/openssl to them.
This doesn't work on Windows.
This change moves the headers to live in include/openssl. In cases where
some symlinks pointed to the same header, I've added a file that just
includes the intended target. These cases are all for backwards-compat.
Change-Id: I6e285b74caf621c644b5168a4877db226b07fd92
Reviewed-on: https://boringssl-review.googlesource.com/1180
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Building without RSA support is unreasonable. Changes were made by
running
find . -type f -name *.c | xargs unifdef -m -U OPENSSL_NO_RSA
find . -type f -name *.h | xargs unifdef -m -U OPENSSL_NO_RSA
using unifdef 2.10 and some newlines were removed manually.
Change-Id: Iea559e2d4b3d1053f28a4a9cc2f7a3d1f6cabd61
Reviewed-on: https://boringssl-review.googlesource.com/1095
Reviewed-by: Adam Langley <agl@google.com>
Since crypto/ebcdic.{c,h} are not present in BoringSSL, remove the #ifdefs
Changes were made by running
find . -type f -name *.c | xargs unifdef -m -U CHARSET_EBCDIC
find . -type f -name *.h | xargs unifdef -m -U CHARSET_EBCDIC
using unifdef 2.10.
An additional two ifdefs (CHARSET_EBCDIC_not) were removed manually.
Change-Id: Ie174bb00782cc44c63b0f9fab69619b3a9f66d42
Reviewed-on: https://boringssl-review.googlesource.com/1093
Reviewed-by: Adam Langley <agl@google.com>
Ensure the library can find the right files under /etc/ssl/certs when
running on older systems.
There are many symbolic links under /etc/ssl/certs created by using
hash of the PEM certificates in order for OpenSSL to find those
certificates. Openssl has a tool to help you create hash symbolic
links (tools/c_rehash). However newer versions of the library changed
the hash algorithm, which makes it unable to run properly on systems
that use the old /etc/ssl/certs layout (e.g. Ubuntu Lucid).
This patch gives a way to find a certificate according to its hash by
using both the old and new algorithms. http://crbug.com/111045 is used
to track this issue.
(Imported from Chromium:
http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/openssl/patches.chromium/0003-x509_hash_name_algorithm_change.patch?revision=231571)
Change-Id: Idbc27aba7685c991f8b94cfea38cf4f3f4b38adc
Fixes to host checking wild card support and add support for setting
host checking flags when verifying a certificate chain.
(Imported from upstream's a2219f6be36d12f02b6420dd95f819cf364baf1d)
When a chain is complete and ends in a trusted root checks are also performed
on the TA and the callback notified with ok==1. For consistency do the same for
chains where the TA is not self signed.
(Imported from upstream's b07e4f2f46fc286c306353d5e362cbc22c8547fb)
Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta).
(This change contains substantial changes from the original and
effectively starts a new history.)
