Throughout the code we make the assumption that onPrepareActionMode() is
called right after starting the action mode. However, this is not the case on
Android 5.1.
With this change we call ActionMode.invalidate() right after starting the
action mode which causes onPrepareActionMode() to be invoked.
- onPrepareActionMode must be called before computeBatchDirection
because computeBatchDirection ends up referencing mMarkAsRead /
mMarkAsUnread and mFlag / mUnflag which could be null otherwise.
An interrupted connection attempt to the server yields an SSLException
as well, like this:
E/k9 ( 6937): Caused by: javax.net.ssl.SSLHandshakeException: Connection closed by peer
E/k9 ( 6937): at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
E/k9 ( 6937): at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:302)
E/k9 ( 6937): at com.android.org.conscrypt.OpenSSLSocketImpl.waitForHandshake(OpenSSLSocketImpl.java:598)
E/k9 ( 6937): at com.android.org.conscrypt.OpenSSLSocketImpl.getInputStream(OpenSSLSocketImpl.java:560)
E/k9 ( 6937): at com.fsck.k9.mail.store.ImapStore$ImapConnection.open(ImapStore.java:2459)
We don't want the user to notify of 'certificate problems' in that case.
Fix it by checking whether the SSLException was actually triggered by a
CertificateException.
This bug was present in the Gallery app shipped with Android 2.0.
The time has come to say good-bye. We will never forget you! But only because you're part of our Git history.
Caching is beneficial because it can eliminate redundant cryptographic
computations and network traffic when re-establishing a connection to
the same server, thus saving time and conserving power.
SslHelper has been removed, and its functionality has been transferred
into TrustedSocketFactory. The added layer of indirection wasn't really
simplifying anything. It's now easier to see what happens when
createSocket() is invoked.
A new instance of SecureRandom is no longer passed to SSLContext.init().
Instead, null is passed.
The (default) provider of the TLS SSLContext used is OpenSSLProvider,
which provides an SSLSocket instance of type OpenSSLSocketImpl. The only
use of SecureRandom is in OpenSSLSocketImpl.startHandshake(), where it is
used to seed the OpenSSL PRNG with additional random data. But if
SecureRandom is null, then /dev/urandom is used for seeding instead.
Meanwhile, the default provider for the SecureRandom service is
OpenSSLRandom, which uses the OpenSSL PRNG as its data source. So we were
effectively seeding the OpenSSL PRNG with itself. That's probably okay
(we trust that the OpenSSL PRNG was properly initialized with random data
before first use), but using /dev/urandom would seem like a better source
(or at least as good a source) for the additional seed data added with
each new connection.
Note that our PRNGFixes class replaces the default SecureRandom service
with one whose data source is /dev/urandom for certain vulnerable API
levels anyway. (It also makes sure that the OpenSSL PRNG is properly
seeded before first use for certain vulnerable API levels.)
