History has shown there are bugs in not setting the error code
appropriately, which makes any decision making based on
|ERR_peek_last_error|, etc. suspect. Also, this call was interfering
with the link-time optimizer's ability to discard the implementations of
many functions in crypto/err during dead code elimination.
Change-Id: Iba9e553bf0a72a1370ceb17ff275f5a20fca31ec
Reviewed-on: https://boringssl-review.googlesource.com/5748
Reviewed-by: Adam Langley <agl@google.com>
This is useful to skip an optional element, and mirrors the behaviour of
CBS_get_optional_asn1_octet_string.
Change-Id: Icb538c5e99a1d4e46412cae3c438184a94fab339
Reviewed-on: https://boringssl-review.googlesource.com/5800
Reviewed-by: Adam Langley <agl@google.com>
If the two extensions select different next protocols (quite possible since one
is server-selected and the other is client-selected), things will break. This
matches the behavior of NSS (Firefox) and Go.
Change-Id: Ie1da97bf062b91a370c85c12bc61423220a22f36
Reviewed-on: https://boringssl-review.googlesource.com/5780
Reviewed-by: Adam Langley <agl@google.com>
Don't dereference |d| when |top| is zero. Also test that various BIGNUM
methods behave correctly on zero/even inputs.
(Imported from upstream's cf633fa00244e39eea2f2c0b623f7d5bbefa904e.)
We already had the BN_div and BN_MONT_CTX_set tests, but align them with
upstream's for consistency.
Change-Id: Ice5d04f559b4d5672e23c400637c07d8ee401727
Reviewed-on: https://boringssl-review.googlesource.com/5783
Reviewed-by: Adam Langley <agl@google.com>
BN_rand generates a single-word zero BIGNUM with quite a large
probability.
A zero BIGNUM in turn will end up having a NULL |d|-buffer, which we
shouldn't dereference without checking.
(Imported from upstream's 9c989aaa749d88b63bef5d5beeb3046eae62d836.)
Change-Id: Ic4d113e4fcf4ea4c0a4e905a1c4ba3fb758d9fc6
Reviewed-on: https://boringssl-review.googlesource.com/5782
Reviewed-by: Adam Langley <agl@google.com>
If the seed value for dsa key generation is too short (< qsize),
return an error.
(Imported from upstream's 1d7df236dcb4f7c95707110753e5e77b19b9a0aa and
df1565ed9cebb6933ee7c6e762abcfefd1cd3846.)
This switches the trigger for random seed from seed_len = 0 to seed_in =
NULL.
Change-Id: I2e07abed754c57ef9d96b02a52ba6d260c3f5fb9
Reviewed-on: https://boringssl-review.googlesource.com/5781
Reviewed-by: Adam Langley <agl@google.com>
See also upstream's c8491de393639dbc4508306b7dbedb3872b74293.
Change-Id: I017fb137d6d93b6abb82fdb03f02be8292963d0d
Reviewed-on: https://boringssl-review.googlesource.com/5767
Reviewed-by: Adam Langley <agl@google.com>
It's supposed to be void*. The only reason this was working was that it was
only called in C which happily casts from void* to T*. (But if called in C++ in
a macro, it breaks.)
Change-Id: I7f765c3572b9b4815ae58da852be1e742de1bd96
Reviewed-on: https://boringssl-review.googlesource.com/5760
Reviewed-by: Adam Langley <agl@google.com>
This begins decoupling the transport from the SSL state machine. The buffering
logic is hidden behind an opaque API. Fields like ssl->packet and
ssl->packet_length are gone.
ssl3_get_record and dtls1_get_record now call low-level tls_open_record and
dtls_open_record functions that unpack a single record independent of who owns
the buffer. Both may be called in-place. This removes ssl->rstate which was
redundant with the buffer length.
Future work will push the buffer up the stack until it is above the handshake.
Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but
return a slightly larger enum due to other events being possible. Likewise the
handshake state machine will be detached from its buffer. The existing
SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc.,
combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why
ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly
different needs.)
The new buffering logic does not support read-ahead (removed previously) since
it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added
if desired. The old buffering logic wasn't quite right anyway; it tried to
avoid the memmove in some cases and could get stuck too far into the buffer and
not accept records. (The only time the memmove is optional is in DTLS or if
enough of the record header is available to know that the entire next record
would fit in the buffer.)
The new logic also now actually decrypts the ciphertext in-place again, rather
than almost in-place when there's an explicit nonce/IV. (That accidentally
switched in https://boringssl-review.googlesource.com/#/c/4792/; see
3d59e04bce96474099ba76786a2337e99ae14505.)
BUG=468889
Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2
Reviewed-on: https://boringssl-review.googlesource.com/5715
Reviewed-by: Adam Langley <agl@google.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>
msbuild was complaining that with warning MSB8012 that |TargetPath|
does not match the Linker's OutputFile property value. The problem
was caused by the wrong ordering of the setting of build properties
and the inclusion of the built-in property sheets.
Make default warnings stricter in mk/top_of_makefile.mk, and then
disable the extra warnings as necessary in mk/ring.mk, in order to sync
ring's build system with mozilla::pkix's build system. Also, use spaces
consistently for indention, instead of a mix of spaces and tabs.
It would be nice to keep the one-shot functions around since they are
convenient, but there's not any good, backward-compatible, way to
remove the shared static buffer option. In particular, there are likely
to be many callers of these functions that expect them to never fail,
and so returning |NULL| when the caller doesn't supply a buffer is not
likely to work well in all cases. Consequently, it's better to fail
hard at build time.
The change to add explicitly-deleted constructors and assignemnt
operators in aead_test.cc and digest_test.cc broke GCC 4.8 builds.
Those changes were made to prevent MSVC from issuing these warnings:
* C4623: default constructor was implicitly defined as deleted
because a base class default constructor is inaccessible or
deleted.
* C4626: assignment operator was implicitly defined as deleted
because a base class assignment operator is inaccessible or
deleted.
* C5027: move assignment operator was implicitly defined as deleted
because a base class move assignment operator is inaccessible
or deleted.
All of these warnigns are just "Warning: we didn't do something
impossible in violation of the C++ language semantics" so they are safe
to disable. Even without considering the GCC 4.8 breakage, this is a
better fix.
* Silence some warnings about things that MSVC 2015 warns about that
MSVC 2013 didn't.
* Change the solution so that it opens in Visual Studio 2015 if Visual
Studio 2015 is installed.
* Change ToolsVersion to 14.0 in the project files so that Visual
Studio 2015 does not put a warning in the build log about the version
being 12.0. This means that Visual Studio 2013 will have a warning,
but the warning is harmless, and if we have to choose, it's better
for VS 2013 to warn than VS 2015 to warn, in the long term. See
https://github.com/Microsoft/msbuild/issues/52#issuecomment-88674094.
* Build with the VS 2013 XP-compatible toolchain if using Visual Studio
2013 (including its msbuild); Otherwise build with the Visual Studio
2015 XP-compatible toolchain. See
https://social.msdn.microsoft.com/Forums/vstudio/en-US/ \
d06c3741-c637-4627-9b1a-1e068803a067/ \
setting-platformtoolset-value-based-on-vs-version.
Previously, sha-x86_64.pl (was sha512-x86_64.pl) was used to generate
both sha256-x86_64.S and sha512-x86_64.S. This required special build
logic in ring.mk and also would have required special logic in the
msbuild project files. This commit adds dedicated perlasm source files
for both, and there's now a 1-to-1 correspondence between perlasm
scripts and output files, which avoids any need for special-case logic
in the build system.
The same goes for sha-armv8.pl (was sha512-armv8.pl).
This commit prepares for the addition of dedicated
sha256-{x86_64,armv8}.pl and sha512-{x86_64,armv8}.pl scripts, in order
to create a 1-to-1 mapping of source .pl scripts to generated
.S assembly language files. This is a separate commit so that git tools
recognize the renames correctly.
Much of the repetitive logic was put into mk/Common.props,
mk/Windows.props, and mk/WindowsTest.props. There is still a lot of
repetitive logic in the test project files that should be moved to
WindowsTest.props in the future. (In fact, it would be better if the
build system were modified in the future to work like CMake does,
(re-)generating the necessary project files during the build.)
Regular (OPENSSL_NO_ASM) mode will come in a later commit.
I've marked the Visual Studio files as eol=crlf in .gitattributes for
now. This should be the least painful option, since it any CRLF
conversion would create problems for for people sharing a source tree
across platforms (e.g. a shared folder in a VM), and because Visual
Studio IDE resets the files back to CR/LF line endings whenever a
change to project or solution settings is made using its GUI. There is
no license comment in these files because Visual Studio strips comments
when changes are made using the GUI.
Travis CI doesn't have a new enough version of CMake readily available,
and I've been wanting to replace the CMake-based build system for other
reasons. This kills the Windows support, but I'm intending to add a
native msbuild build system for Windows soon. Also, this builds in
OPENSSL_NO_ASM mode for now.
