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.)
For support of the dark and light themes.
Also:
Redefine mFolded and call it mIsFolded. Previously,
the view started with mFolded = false (which implies to me
the initial state is unfolded) and yet the view
started in a folded state, which seemed contradictory.
Create updateFoldedState() with code from onClick() (In
preparation for subsequent commit.)
It only applied to pre-ICS devices.
ConnectivityManager.ACTION_BACKGROUND_DATA_SETTING_CHANGED is no longer
broadcast.
ConnectivityManager.getBackgroundDataSetting() always returns true.
This was dead code. The exception message will always start with either
"SMTP response is 0 length" from checkLine() or else "Negative SMTP reply"
from NegativeSmtpReplyException().
The problem originated from way back before 4.904.
The constructor now saves the certificate chain, so the code to retrieve
it again or to perform any additional error checking in
getCertificateChain() is no longer needed.
The constructor now retrieves and saves the private key so that any
resulting errors are detected sooner.
Methods that retrieve the alias perform checks to assure that the client
cert. satisfies the requested issuers and key type. It's known that
Sendmail may provide a list of issuers in its certificate request, but
then may authenticate against a much larger set of CAs, but then later
reject the mail because the client certificate was not acceptable.
Vetting against the issuer list helps detect such certificate problems
sooner (upon connection) rather than later (upon transmission of mail).
Earlier error detection is necessary so that errors may be presented to
the user during account setup.
Portions of these modifications are based on code from KeyManagerImpl:
https://android.googlesource.com/platform/external/conscrypt/+/master/src/main/java/org/conscrypt/KeyManagerImpl.java
Move KeyChainKeyManager to com.fsck.k9.net.ssl because it is used by
SslHelper and because the class extends X509ExtendedKeyManager, which is
in javax.net.ssl.
The problem can be observed if, when modifying the outgoing server
settings, you change the state of the mRequireLoginView check box,
then change the screen orientation.
This is necessary because the OnCheckChanged listener (which
normally updates the view visibility) is not yet set. (The listeners
are set up after view initialization so that they only fire on
user input.)
It should not be triggered when the instance state is restored
with an AuthType spinner selection of EXTERNAL.
The logic here for the AuthType spinner is similar to that of
the parent commit for the SecurityType spinner.
The problem: begin modifying the server settings by changing the security
type (which will change the port to a default value), then change the port
to a custom value, then change screen orientation. The default port value
is restored, wiping out the custom value.
When onRestoreInstanceState() is called, the custom port value is
restored. But the spinner doesn't actually restore its state at that
time. Instead, it waits until View.layout(), at which time it posts a
runnable to call onItemSelected() if the restored state doesn't match the
state initialized in onCreate(). When onItemSelected() is eventually run
sometime later, it wipes out the custom port value that was restored.
The solution is to keep track of the spinner state ourselves and only
revert the port to a default when we see the spinner state changed by the
user.
This problem goes back to 4.904 and before.
For convenience. Implemented in onCheckChanged().
As a consequence, onCheckChanged() must not be triggered when the instance
state is restored (would occur if the check box state was checked when
saved), otherwise the certificate chooser would pop up once the state was
restored. Therefore, all listeners have been moved into
initializeViewListeners() which is invoked after the state has been
restored.
Because onCheckChanged() is no longer triggered in
onRestoreInstanceState(), updateViewVisibility() was implemented to
restore the view visibility.
This is done when the SASL EXTERNAL mechanism isn't advertised (indicating
the possibility that the server did not accept the client certificate) or
when the command for authenticating with SASL EXTERNAL fails.
The CertificateValidationException will trigger a notification to the user
that there's an authentication problem that needs addressing.
Also, there were instances where CertificateValidationException was being
thrown with a new CertificateException as the cause for the purpose of
notifying the user when STARTTLS is not available. This has been slightly
simplified by eliminating the need to include a new CertificateException
as a cause.
