Many of the compatibility issues are described at
https://msdn.microsoft.com/en-us/library/mt612856.aspx. The macros
that suppressed warnings on a per-function basis no longer work in
Update 1, so replace them with #pragmas. Update 1 warns when |size_t|
arguments to |printf| are casted, so stop doing that casting.
Unfortunately, this requires an ugly hack to continue working in
MSVC 2013 as MSVC 2013 doesn't support "%zu". Finally, Update 1 has new
warnings, some of which need to be suppressed.
---
Updated by davidben to give up on suppressing warnings in crypto/x509 and
crypto/x509v3 as those directories aren't changed much from upstream. In each
of these cases, upstream opted just blindly initialize the variable, so do the
same. Also switch C4265 to level 4, per Microsoft's recommendation and work
around a bug in limits.h that happens to get fixed by Google include order
style.
(limits.h is sensitive to whether corecrt.h, pulled in by stddef.h and some
other headers, is included before it. The reason it affected just one file is
we often put the file's header first, which means base.h is pulling in
stddef.h. Relying on this is ugly, but it's no worse than what everything else
is doing and this doesn't seem worth making something as tame as limits.h so
messy to use.)
Change-Id: I02d1f935356899f424d3525d03eca401bfa3e6cd
Reviewed-on: https://boringssl-review.googlesource.com/7480
Reviewed-by: David Benjamin <davidben@google.com>
The high bits of the type get used for the V_ASN1_NEG bit, so when used with
ASN1_ANY/ASN1_TYPE, universal tags become ambiguous. This allows one to create
a negative zero, which should be impossible. Impose an upper bound on universal
tags accepted by crypto/asn1 and add a test.
BUG=590615
Change-Id: I363e01ebfde621c8865101f5bcbd5f323fb59e79
Reviewed-on: https://boringssl-review.googlesource.com/7238
Reviewed-by: Adam Langley <agl@google.com>
This change causes cipher_test to test the EVP cipher interfaces with
various chunk sizes and adds a couple of large tests of GCM. This is
sufficient to uncover the issue that would have been caused by a3d9528e,
had the AVX code been enabled.
Change-Id: I58d4924c0bcd11a0999c24a0fb77fc5eee71130f
Reviewed-on: https://boringssl-review.googlesource.com/7192
Reviewed-by: David Benjamin <davidben@google.com>
That was probably more complexity than we needed. Nothing uses it
anymore, now that getting to the PKCS#8 logic isn't especially tedious.
Change-Id: I4f0393b1bd75e71664f65e3722c14c483c13c5cf
Reviewed-on: https://boringssl-review.googlesource.com/6867
Reviewed-by: Adam Langley <agl@google.com>
As with SPKI parsers, the intent is make EVP_PKEY capture the key's
constraints in full fidelity, so we'd have to add new types or store the
information in the underlying key object if people introduce variant key
types with weird constraints on them.
Note that because PKCS#8 has a space for arbitrary attributes, this
parser must admit a hole. I'm assuming for now that we don't need an API
that enforces no attributes and just ignore trailing data in the
structure for simplicity.
BUG=499653
Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8
Reviewed-on: https://boringssl-review.googlesource.com/6866
Reviewed-by: Adam Langley <agl@google.com>
Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each
with different ways to set signature parameters. SPKIs themselves can
get complex with id-RSASSA-PSS keys which come with various constraints
in the key parameters. This suggests we want a common in-library
representation of an SPKI.
This adds two new functions EVP_parse_public_key and
EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and
implements X509_PUBKEY functions with them. EVP_PKEY seems to have been
intended to be able to express the supported SPKI types with
full-fidelity, so these APIs will continue this.
This means future support for id-RSASSA-PSS would *not* repurpose
EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies
acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and
the data pointer would be some (exposed, so the caller may still check
key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX
implementation would enforce the key constraints. If RSA_PSS_KEY would
later need its own API, that code would move there, but that seems
unlikely.
Ideally we'd have a 1:1 correspondence with key OID, although we may
have to fudge things if mistakes happen in standardization. (Whether or
not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate
EVP_PKEY type.)
DSA parsing hooks are still implemented, missing parameters and all for
now. This isn't any worse than before.
Decoupling from the giant crypto/obj OID table will be a later task.
BUG=522228
Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c
Reviewed-on: https://boringssl-review.googlesource.com/6861
Reviewed-by: Adam Langley <agl@google.com>
This centralizes the conditional logic into openssl/base.h so that it
doesn't have to be repeated. The name |OPENSSL_PRINTF_FORMAT_FUNC| was
chosen in anticipation of eventually defining an
|OPENSSL_PRINTF_FORMAT_ARG| for MSVC-style parameter annotations.
Change-Id: I273e6eddd209e696dc9f82099008c35b6d477cdb
Reviewed-on: https://boringssl-review.googlesource.com/6909
Reviewed-by: David Benjamin <davidben@google.com>
This change imports the following changes from upstream:
6281abc79623419eae6a64768c478272d5d3a426
dfd3322d72a2d49f597b86dab6f37a8cf0f26dbf
f34b095fab1569d093b639bfcc9a77d6020148ff
21376d8ae310cf0455ca2b73c8e9f77cafeb28dd
25efcb44ac88ab34f60047e16a96c9462fad39c1
56353962e7da7e385c3d577581ccc3015ed6d1dc
39c76ceb2d3e51eaff95e04d6e4448f685718f8d
a3d74afcae435c549de8dbaa219fcb30491c1bfb
These contain the “altchains” functionality which allows OpenSSL to
backtrack when chain building.
Change-Id: I8d4bc2ac67b90091f9d46e7355cae878b4ccf37d
Reviewed-on: https://boringssl-review.googlesource.com/6905
Reviewed-by: Adam Langley <agl@google.com>
Chromium's toolchains may now assume C++11 library support, so we may freely
use C++11 features. (Chromium's still in the process of deciding what to allow,
but we use Google's style guide directly, toolchain limitations aside.)
Change-Id: I1c7feb92b7f5f51d9091a4c686649fb574ac138d
Reviewed-on: https://boringssl-review.googlesource.com/6465
Reviewed-by: Adam Langley <agl@google.com>
Start converting the ones we can right now. Some of the messier ones
resize init_buf rather than assume the initial size is sufficient, so
those will probably wait until init_buf is gone and the handshake's
undergone some more invasive surgery. The async ones will also require
some thought. But some can be incrementally converted now.
BUG=468889
Change-Id: I0bc22e4dca37d9d671a488c42eba864c51933638
Reviewed-on: https://boringssl-review.googlesource.com/6190
Reviewed-by: Adam Langley <alangley@gmail.com>
This consists mostly of re-adding OpenSSL's implementation of PBKDF2
(very loosely based upon e0d26bb3). The meat of it, namely
|PKCS5_PBKDF2_HMAC|, was already present, but unused.
In addition, |PKCS8_encrypt| and |PKCS8_decrypt| must be changed to
not perform UCS-2 conversion in the PBES2 case.
Change-Id: Id170ecabc43c79491600051147d1d6d3c7273dbc
Reviewed-on: https://boringssl-review.googlesource.com/5745
Reviewed-by: Adam Langley <agl@google.com>
Match the other stack-allocated types in that we expose a wrapper function to
get them into the zero state. Makes it more amenable to templates like
ScopedOpenSSLContext.
Change-Id: Ibc7b2b1bc0421ce5ccc84760c78c0b143441ab0f
Reviewed-on: https://boringssl-review.googlesource.com/5753
Reviewed-by: Adam Langley <agl@google.com>
This is the only test amongst the tests for core crypto functionality
that depends on crypto/bio. This change removes that dependency. This
also factors out the duplicative hexdump logic into a shared function.
Change-Id: Ic280a71d086555a6993c05f183b94e1d38b60932
Reviewed-on: https://boringssl-review.googlesource.com/5622
Reviewed-by: Adam Langley <agl@google.com>
The error condition was checked for, but the return statement was
missing.
Change-Id: I92f89809a7a112fdece49a2a8a8628ff2da8e0da
Reviewed-on: https://boringssl-review.googlesource.com/5610
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
When using CMake to build with MSVC, MSVC complains about unreachable
code in the <xtree> header. This incantation silences that.
Change-Id: I5fc5305dc816a009a4c59501b212fd11e290637d
Reviewed-on: https://boringssl-review.googlesource.com/5552
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
If gdb is attached, it's convenient to be able to continue running.
Change-Id: I3bbb2634d05a08f6bad5425f71da2210dbb80cfe
Reviewed-on: https://boringssl-review.googlesource.com/5125
Reviewed-by: Adam Langley <agl@google.com>
Per malloc(3):
The UNIX 98 standard requires malloc(), calloc(), and realloc() to set
errno to ENOMEM upon failure. Glibc assumes that this is done (and the
glibc versions of these routines do this); if you use a private malloc
implementation that does not set errno, then certain library routines may
fail without having a reason in errno.
Notably, thread_test otherwise fails an assertion deep in glibc.
Change-Id: Ia2c0ab306987476e7d6570d4bbf04a2641398925
Reviewed-on: https://boringssl-review.googlesource.com/5111
Reviewed-by: Adam Langley <agl@google.com>
At some point we might need to make this defined by the consumer.
BUG=495146
Change-Id: Iedac305f234cb383799a5afc14046cd10fb3256a
Reviewed-on: https://boringssl-review.googlesource.com/4963
Reviewed-by: Adam Langley <agl@google.com>
bn_test's output is meant to be piped to bc, but this got broken somewhat:
- OpenSSL uses uppercase hex rather than BoringSSL's lowercase. bc only accepts
uppercase. Document that this needs some shell pipeline until we replace
them with better tests because this is all ridiculous.
- Some stderr outputs moved to stdout to avoid cluttering stdout. Just remove
them. The operations are fast enough to not need progress.
- To cut down on noise, only write the bc transcript given a command-line flag.
Also remove the -results flag since it's pointless. (It writes only the
results and not the inputs.)
Change-Id: I08f87cac1e03fab461f0dc40b9d4285bd877807d
Reviewed-on: https://boringssl-review.googlesource.com/4896
Reviewed-by: Adam Langley <agl@google.com>
Currently far from passing and I haven't even tried with a leak checker yet.
Also bn_test is slow.
Change-Id: I4fe2783aa5f7897839ca846062ae7e4a367d2469
Reviewed-on: https://boringssl-review.googlesource.com/4794
Reviewed-by: Adam Langley <agl@google.com>
Derived from upstream's new evp_test. The tests were taken from upstream
but tweaked so the diff from the old cipher_test.txt is more obvious.
Change-Id: Ic82593a8bb6aaee9b69fdc42a8b75516b03c1c5a
Reviewed-on: https://boringssl-review.googlesource.com/4707
Reviewed-by: Adam Langley <agl@google.com>
This imports the EVP_PKEY test data of upstream's evptests.txt, but
modified to fit our test framework and with a new test driver. The
remainder of the test data will be imported separately into aead_test
and cipher_test.
Some minor changes to the test format were made to account for test
framework differences. One test has different results since we don't
support RSA signatures with omitted (rather than NULL) parameters.
Otherwise, the biggest difference in test format is that the ad-hoc
result strings are replaced with checking ERR_peek_error.
Change-Id: I758869abbeb843f5f2ac6c1cbd87333baec08ec3
Reviewed-on: https://boringssl-review.googlesource.com/4703
Reviewed-by: Adam Langley <agl@google.com>
This adds a file-based test framework to crypto/test. It knows how to
parse formats similar to either upstream's evp_test and our aead_test.
hmac_test has been converted to that with tests from upstream's
evp_test. Upstream tests it against the deprecated EVP_PKEY_HMAC API,
which will be tested by running evp_test against the same input file, to
avoid having to duplicate the test vectors. hmac_test runs those same
inputs against the supported HMAC_CTX APIs.
Change-Id: I9d2b6adb9be519760d1db282b9d43efd6f9adffb
Reviewed-on: https://boringssl-review.googlesource.com/4701
Reviewed-by: Adam Langley <agl@google.com>
The interface for this is very similar to upstream, but the code is
quite different.
Support for “resuming” (i.e. calling |CMAC_Final| and then computing the
CMAC for an extension of the message) has been dropped. Also, calling
|CMAC_Init| with magic argument to reset it has been replaced with
|CMAC_Reset|.
Lastly, a one-shot function has been added because it can save an
allocation and that's what most callers actually appear to want to do.
Change-Id: I9345220218bdb16ebe6ca356928d7c6f055d83f6
Reviewed-on: https://boringssl-review.googlesource.com/4630
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This is taken from upstream, although it originally came from us. This
will only take effect on 64-bit systems (x86-64 and aarch64).
Before:
Did 1496 ECDH P-256 operations in 1038743us (1440.2 ops/sec)
Did 2783 ECDSA P-256 signing operations in 1081006us (2574.5 ops/sec)
Did 2400 ECDSA P-256 verify operations in 1059508us (2265.2 ops/sec)
After:
Did 4147 ECDH P-256 operations in 1061723us (3905.9 ops/sec)
Did 9372 ECDSA P-256 signing operations in 1040589us (9006.4 ops/sec)
Did 4114 ECDSA P-256 verify operations in 1063478us (3868.4 ops/sec)
Change-Id: I11fabb03239cc3a7c4a97325ed4e4c97421f91a9
Along the way, fix a host of missing failure checks. This will save some
headache when it comes time to run these under the malloc failure tests.
Change-Id: I3fd589bd094178723398e793d6bc578884e99b67
Reviewed-on: https://boringssl-review.googlesource.com/4126
Reviewed-by: Adam Langley <agl@google.com>
This is in preparation for using RAII in the unit tests. Those tests are built
in Chromium as well, but Chromium does not have C++11 library support across
all its toolchains. Compiler support is available, so add a partial
reimplementation of std::unique_ptr and std::move under crypto/test/. The
scopers for the crypto/ library are also moved there while the ones for ssl/
stay in ssl/test/.
Change-Id: I38f769acbc16a870db34649928575c7314b6e9f6
Reviewed-on: https://boringssl-review.googlesource.com/4120
Reviewed-by: Adam Langley <agl@google.com>
