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.
If the alias is empty or null, don't bother using KeyChainKeyManager.
If the alias is not empty, confirm that it is associated with a
certificate, otherwise throw a CertificateValidationException
which will notify the user of the problem and ask the user to
check the server settings.
Likewise, the user is notified if the client certificate was
not accepted by the server.
If the user chooses client certificate authentication,
immediately pop up the certificate chooser.
If the user chooses password authentication, move the focus to the
password View.
With this commit, KeyChainKeyManager no longer throws the exception and
AccountSetupCheckSettings no longer catches it.
It was being thrown when the server requested a client certificate but no
client certificate alias had been configured for the server.
The code was making the incorrect assumption that the server would only
request a client certificate when such a certificate was *required*.
However, servers can be configured to accept multiple forms of
authentication, including both password authentication and client
certificate authentication. So a server may request a certificate without
requiring it. If a user has not configured a client certificate, then
that should not be treated as an error because the configuration may be
valid and the server may accept it.
The only indication that a certificate is *required* is when a
SSLProtocolException is thrown, caused by a SSLHandshakeException
resulting from a fatal handshake alert message received from the server.
Unfortunately, such a message is fairly generic and only "indicates that
the sender was unable to negotiate an acceptable set of security
parameters given the options available." So there is no definitive way to
know that a client certificate is required.
Also, KeyChainKeyManager.getCertificateChain() and getPrivateKey() no
longer throw IllegalStateException(). These methods are permitted to
return null, and such a response is appropriate if the user has deleted
client certificates from the device. Again, this may or may not cause the
server to abort the connection, depending on whether the server *requires*
a client certificate.
