| Age | Commit message (Collapse) | Author |
|---|
|
Including it causes problems in Android CTS because it results in
tests being added twice, which CTS doesn't handle well.
(cherry picked from commit 82a40039eae6da8276f04af32afd4be6549a991b)
Test: cts -m CtsLibcoreTestCases -t com.android.org.conscrypt (verified test count)
Bug: 78550712
Change-Id: I08b67ad71002775d61f5d117c7b91b615fe48253
|
|
This uses a read/write lock around the ssl instance variable for
NativeSsl. The write lock is only taken during close(), where ssl is
cleared, so all other operations can proceed in parallel with one
another. I only added locking to the read- and write-style methods in
the class, rather than to methods that only read or write a property,
since the latter tend to be used only right when the SSL is created
and it would add a lot of noise to the code to lock everywhere, but
it's possible we want to add that as well for complete safety.
This should solve some longstanding but infrequent crashes we've seen
that involve race conditions with finalizers and other related
situations.
This is a cherry-pick of 47d96e94c8645d23a8f66033b4d124142ddc72b9 from
https://github.com/google/conscrypt.
Bug: 70507413
Test: cts -m CtsLibcoreTestCases -t com.android.org.conscrypt
Change-Id: Ie045232e08638ffd4199ac4b971ce12a72b402b1
|
|
At least some of the native crashes are caused by race conditions
associated with some threads passing the isClosed() check at the
beginning of an operation while the close() method is executing.
Clearing the SSL variable before freeing the native resources should
reduce the frequency of this race condition.
Bug: 70507413
Test: cts -m CtsLibcoreTestCases -t com.android.org.conscrypt
Change-Id: Ibb5fef327ae1698ab362a7447e4b4150870ae93e
|
|
The legacy OpenSSL APIs in BoringSSL don't parse ASN1_TIME values
until they're used, which means that the existing code could explode
in the middle of X509Certificate.getNotAfter() and similar
Date-returning calls, and those calls aren't declared to throw
anything. Instead, read and cache the values in the constructor,
where we can throw a relevant exception if necessary.
We have to clone the Date values when returning them because Date is
mutable.
Bug: 77510210
Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=824499
Test: cts -m CtsLibcoreTestCases -t com.android.org.conscrypt
Change-Id: I7c7928c172605508916f27e10e24117c91a9a796
Merged-In: Ib73ffb52ec67674f08a800cfcddb2ca87ab01b1d
|
|
This was originally added to libcore.javax.net.ssl.SSLEngineTest in
goog/3640692, but this branch and downstream branches have deleted
that class and moved the tests for it to this class.
Bug: 73251618
Test: cts -m CtsLibcoreTestCases -t com.android.org.conscrypt
Change-Id: Ieb033ed3873e05cc5b59adf626129e4dbc54c403
|
|
am: 4a85e8dc86
Change-Id: I13fd2b646c69997361bebb44cc3725d5304878e0
|
|
am: 2b7f3068ef am: 8b0dc16195
am: 9d91a852ef
Change-Id: Id7ab4499f7c3c65a0d62235662cb8b90b3126169
|
|
am: 2b7f3068ef
am: 8b0dc16195
Change-Id: I33c4de7f3991b5c57d123b4ecb4a7005eb7f7692
|
|
am: 2b7f3068ef
Change-Id: Iea0c7b5c7af7caf45a22d3ac9df57b0fa37e27ff
|
|
|
|
am: 846446f1d9
Change-Id: I455c682a0da126675a71e6264ecbe7a47c38ed56
|
|
am: 4cf5056b33
Change-Id: I9ec0e3ce6ccd913c5a1bd07ee24806299d1b1934
|
|
am: 7e5fb7c809
Change-Id: I3637f72dd07a932df32cb89c71dfbfb8e29d4a6a
|
|
Reverts the change in SSLSocket exception behavior.
Bug: 73922763
Test: cts -m CtsLibcoreTestCases -t com.android.org.conscrypt.javax.net.ssl
Change-Id: Id8dfa1c81335cd6c707d8432073fbd40e8edf6c6
|
|
We've had reports from people that depended on "normal" connection
termination (such as in HTTP where the peer sends data and then closes
the TCP connection) returning -1 from read(), and in some cases this
change causes read() to throw a SocketException in that circumstance.
Rather than causing such a fundamental change in behavior, probably
better to just adjust the test to allow for a -1 return.
This reverts commit d84f6f57b216ab53dc3a71d30fd2252ce2208c13.
|
|
Test: make
Bug: 73635411
Change-Id: I921b287ac13227a416d406e0399dbcddd0f2986b
|
|
am: d89949b722
Change-Id: I9ae2155dc8468989c24ec04f53961a2ce70e48e8
|
|
am: c432e46046
Change-Id: Iec8ee13cbce0e1f6c4073de770f9f9b02bb3ad84
|
|
am: f753e05a9e
Change-Id: If3cadff5308d3af1ea912d07db62af0e75cdaf11
|
|
Only change from upstream is throwing a new exception in one case.
Bug: 73596939
Test: cts -m CtsLibcoreTestCases -t com.android.org.conscrypt.javax.net.ssl
Change-Id: I36f2cd5682b13793fce480e08618ffe2bba4a48e
|
|
am: ffccce6651
Change-Id: Ieeb873aa5d52c67551377cbcf0a61b01f5709edb
|
|
SSLSocketTest#test_SSLSocket_interrupt_readWrapperAndCloseUnderlying
is failing periodically on our internal continuous builds, and it
appears to be happening due to a race condition.
The test is testing what happens when an SSLSocket that's wrapping an
underlying Socket is blocked on a read and then underlying socket is
closed by another thread. There appears to be a race condition
between the OS waking up the reading thread and the write of -1 to
java.io.FileDescriptor's private field. If the reading thread wakes
up and proceeds past the check of the file descriptor's validity
before the field write is visible, then it will attempt to call
SSL_read() and get ERR_SSL_SYSCALL, and it responds by returning -1,
whereas the test expects SocketException to be thrown (which it does
if the file descriptor is invalid).
This changes the code to always throw SocketException when
ERR_SSL_SYSCALL is reported with a return value of 0, which the
BoringSSL docs say happens "if the transport returned EOF", which
should mean the file descriptor is closed.
|
|
am: 5b0eb6591e
Change-Id: I3320a12884e67c22e07bf406c7742bbe08227374
|
|
am: 1b7ad09993
Change-Id: I0ac599a1470fca5027fb514c051055c1f45a8d28
|
|
When the SSLEngine overload that accepts an array of ByteBuffers is
called with heap buffers for both the source and destination, those
heap buffers are converted to direct buffers for passing to JNI by way
of copying them to a single temporary direct buffer. A bug in the
reading of the encrypted data out of BoringSSL resulted in the data
being placed at the wrong offset of the temporary buffer, meaning that
the output data was prefixed in the worst case by the plaintext.
Bug: 73251618
Test: cts -m CtsLibcoreTestCases -t libcore.javax.net.ssl
Change-Id: I9b1a167f9a5ccd36d6da5cd1a14a80fb3cc73a1f
|
|
Some more finalization safety and a change to the makefile.
Bug: 65476203
Test: cts -m CtsLibcoreTestCases
Change-Id: Ibd77edfa0c2882222f105fae40256d1fcc537ba8
|
|
|
|
|
|
am: 6b731f68e8
Change-Id: I84fc5762fa5cb57cf0822b03eec7d539779028ac
|
|
am: 8f7968d486
Change-Id: I1ebdfa0558e8b65be6e685a51e4476c0943ac07c
|
|
am: 4fc3293b81
Change-Id: Id1dd0b048b7dbd98925e3dee6a5e0bdb10f3ff2e
|
|
The only real change from upstream is the inclusion of crypto tests in
Conscrypt.
Bug: 65476203
Test: cts -m CtsLibcoreTestCases
Change-Id: Icee3c9bb6e7f8a0a5ff6869cddc3a0263a4c9264
|
|
The provider has different names in different places.
|
|
The current format is a bit mixed-up and omits a few necessary steps
(like releasing the Android build). Pare it down to just the list of
instructions, add everything that's necessary, and put them into the
proper order so it can just be executed from the top down.
|
|
|
|
I use emacs as an editor and it's annoying when it's not there.
|
|
|
|
am: 0933dfb7a3
Change-Id: I2877f518a5fc2bb39ff4d09a373080f03eb43e60
|
|
am: 8fb98a90b1
Change-Id: I3da96a9f87c3b6c32f48f475aa994c6f91398ecc
|
|
am: 730d65c7b4
Change-Id: I253c2a74330f557f6e03e040534cfa3e5bbd3850
|
|
These tests are pulled from AOSP with minor modifications. They test
the behavior of the Cipher, KeyAgreement, and KeyGenerator classes for
all installed providers (which includes Conscrypt when run under the
ConscryptSuite).
Specific modifications made:
* Convert tests to JUnit4 style.
* Fixes for running under OpenJDK and with SunJCE installed.
* Removed tests for classes themselves rather than providers.
Note that these tests are not all up to modern standards in terms of
code style and readability, but I'd like to commit them as-is on the
basis that we can gradually improve them, but they'll do a lot more
work being available and accessible than they would stuck in AOSP
until they can be cleaned up.
* Disable tests when running on HotSpot JRE.
Oracle's JRE refuses to run crypto providers that come from unsigned
jar files. We can't sign the jar files in automated builds and tests
and such, since that would require giving the world access to our
signing key, so just disable those tests when running in an
environment where they can't work.
Also update our Travis build to use OpenJDK 8, since that allows these
tests to run.
* Exclude CipherTest from Java 6 testing for now.
CipherTest uses GCMParameterSpec and AEADBadTagException relatively
widely, and both were introduced in Java 7.
|
|
The main change from upstream is cleaning up our handling of the
BoringSSL error queue.
Bug: 73118000
Test: cts -m CtsLibcoreTestCases
Change-Id: Ic4efc7c73fb9d02cb15129e4499b5c614b90ca07
|
|
When CHECK_ERROR_QUEUE_ON_RETURN is disabled, we need to inform the
compiler that we intended not to use env.
|
|
We need to ensure that the BoringSSL error stack is clear when
returning from native functions, otherwise a later function might
inspect the error stack and interpret it incorrectly.
Adds the compile option CONSCRYPT_CHECK_ERROR_QUEUE which enables the
macro CHECK_ERROR_QUEUE_ON_RETURN. That macro, when enabled, creates
a class that checks the error queue is empty in its destructor. The
macro has been added to almost every native method called from Java,
enforcing that the error queue is empty when we return from native
code back to Java code.
Adds the gradle property checkErrorQueue to enable the code and adds
it to the Travis config.
Also fixes a couple places found by this checking that we were failing
to clear the error queue after handling errors.
|
|
Change throwExceptionIfNecessary to throwExceptionFromBoringSSLError.
The definition changes from throwing an exception if there's an error
on the stack to having a precondition of having an error on the stack.
This makes its behavior and the expected usage more clear (it always
results in an exception pending). This also should let us know if
we're encountering return-failure-but-don't-stack-an-error situations
that we didn't know about.
Normalize function names to throwFooException.
Ensure that we always return immediately after throwing an exception.
Some call sites allowed the exception-throwing branch to fall through
to the return statement from a non-throwing branch, which is unclear,
since that return statement is useless, and runs the risk of
additional code being inserted after the exception.
Fixes #97.
|
|
|
|
|
|
|
|
am: 0a68cb155a
Change-Id: Ie72607404ded322264136bdbcd6950b218c1b1cd
|
|
am: 07aae3a0d5
Change-Id: I9d56b082d283f9ed9753a3f843fd6043974bc27e
|
