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.
The app's minSdkVersion = 15 (Android 4.0.3, Ice Cream Sandwich MR1),
so there's no need to test the API level.
This also removes '@SuppressLint("TrulyRandom")'. I find no
documentation for it, nor do I find any additional lint errors
with its removal.
Previously, with settings of Security=SSL and authentication=certificate,
attempting to change Security=None would (of course) be blocked. So
Security would remain SSL. But the authentication options would then
include "Password, transmitted insecurely", whereas the option should
have remained as "Normal password" (because the security remained SSL).
The problem could have been fixed with a simple shuffling in
updatePortFromSecurityType() so that updateAuthPlainTextFromSecurityType()
was invoked before mPortView.setText(), but the logic for requiring that
ordering was not plain to see. (Although no longer necessary, the
shuffling was done as well.)
Add test for username == "".
Without it, the mRequireLoginView remains checked, and the empty username
and password boxes are not hidden.
The problem occurs if importing an SMTP server that has an
authenticationType, but no username or password (i.e., no authentication
required).
That's the way settings were exported in 4.904 and before.
Specifically, warn and block them when attempting to configure Client
Certificate Authentication in combination with Connection Security = None.
If this were not made obvious to the user, they might not understand why
they are not permitted to tap "Next".
Also, move the initialization of all view listeners out of onCreate() into
initializeViewListeners() which is then called near the end of onCreate(),
helping to assure that the listeners won't be triggered during the
initialization of views inside onCreate().
Previously, it was possible to have "Require sign-in" unchecked and a
"Security = None" setting for the outgoing server and still not be able to
tap "Next" because of a hidden (and irrelevant) "Authentication = Client
certificate" setting.
Check that the user has actually chosen a client certificate in
AccountSetupOutgoing.validateFields().
Also, there's no need to clear the password and certificate fields when
hiding them. The user may accidentally change settings and want to change
them back without wiping out the existing settings.
These options originated in the AOSP email client from which K-9 Mail was
forked. They provide an odd combination of 2 features:
1. Don't bother to authenticate the server's certificate (applies to both
SSL/TLS and STARTTLS); i.e., blindly accept all certificates. This is
generally a bad security policy which is susceptible to MITM attacks.
2. If STARTTLS is selected but the server doesn't claim to support
STARTTLS, then proceed without using encryption. This, too, is a bad
security policy which is susceptible to MITM attacks.
Since the time that K-9 Mail was forked, a couple things have changed:
> K-9 Mail has implemented the ability for users to review and permanently
accept individual certificates that would otherwise fail authentication.
With this ability, there is no need for a user to subject themselves to
the ongoing risks of feature 1. above. Hence, this commit removes feature
1.
> The AOSP email client has changed its behavior and no longer permits a
security downgrade to an unencrypted connection if the server doesn't
claim to support STARTTLS (i.e., they eliminated feature 2. above). K-9
Mail should do the same. It's unlikely that a server is going to provide
STARTTLS on an intermittent basis, so providing a contingency for such
unusual behavior is an unnecessary risk. Hence, this commit removes that
feature as well.
Effect on existing users:
If the old connection security setting was "SSL/TLS (if available)" (which
now gets remapped to "SSL/TLS"), and the server does not provide a
certificate that can be authenticated, then a "Certificate error for
<account name>" notification is generated telling the user to check their
server settings. Tapping the notification takes the user to the relevant
server settings, where the user can tap "Next" to review the certificate
and choose to permanently accept it. This process would occur during the
first syncing of folders after application upgrade or (in the case of
SMTP) during the first attempt to send a message.
If the connection security setting was "STARTTLS (if available)" (which
now gets remapped to "STARTTLS"), and the server does not provide a
certificate that can be authenticated, then the same process as above
would occur.
If the old connection security setting was "STARTTLS (if available)", and
the server doesn't claim to support STARTTLS, then the user would get a
certificate error notification which would lead them to the server's
settings. There they would need to choose a different connection security
-- most likely "NONE". If they didn't change anything but instead just
tapped "Next", the server settings would be checked again and a dialog
would pop up saying, "Cannot connect to server. (STARTTLS connection
security not available)". (The implementation of notifications when
STARTTLS is not available is not actually included here -- it's in the
commit that follows.)
Regarding the changes to providers.xml: in cases where the scheme ended
with "+ssl", the schemes were simply updated by appending "+". In cases
where the scheme ended with "+tls", a check of the server was made to
assure that STARTTLS was available before appending "+" to the scheme.
Domains paran.com and nate.com failed the check and were removed because
no current information could be found. Domains me.com and mac.com also
failed and were updated based on http://support.apple.com/kb/ht4864.
If the user chooses a connection security option which assures the use of
encryption, then the PLAIN auth. option is labeled "Normal password",
otherwise it is labeled "Password, transmitted insecurely".
This is similar to Thunderbird's behavior.
The LOGIN option is no longer offered to users as a choice. This does
*not* eliminate the SASL LOGIN authentication mechanism. Any pre-existing
LOGIN setting or any imported LOGIN setting will still be recognized. In
all cases, a user setting of either "Normal password" or "LOGIN" will
result in the SASL PLAIN mechanism being tried first if available,
otherwise SASL LOGIN will be tried if available.
This mirrors similar behavior that exists for IMAP.
AUTOMATIC = "Automatic"
PLAIN = "Normal password"
CRAM_MD5 = "Encrypted password"
SMTP also uses LOGIN. No localized text was associated with that because
a future commit will remove that option.
(The text is similar to that of Thunderbird's)
Instead, have K9.onCreate initialize the location of the key
store file (similar to what is done with
BinaryTempFileBody.setTempDirectory).
Also, LocalKeyStore.getInstance has been changed so that it
no longer needs to be synchronized.
Proper host name validation was not being performed for certificates
kept in the local keystore. If an attacker could convince a user to
accept and store an attacker's certificate, then that certificate
could be used for MITM attacks, giving the attacker access to all
connections to all servers in all accounts in K-9.
This commit changes how the certificates are stored. Previously, an
entire certificate chain was stored for a server (and any of those
certificates in the chain were available for validating signatures on
certificates received when connecting). Now just the single
certificate for the server is stored.
This commit changes how locally stored certificates are retrieved.
They can only be retrieved using the host:port that the user
configured for the server.
This also fixes issue 1326. Users can now use different certificates
for different servers on the same host (listening to different ports).
The above changes mean that users might have to re-accept certificates
that they had previously accepted and are still using (but only if the
certificate's Subject doesn't match the host that they are connecting
to).
This commit modifies AccountSetupBasics so that it now calls
AccountSetupCheckSettings twice -- once for checking the incoming
settings and once for the outgoing settings. Otherwise, an exception
could occur while checking incoming settings, the user could say
continue (or the user could accept a certificate key), and the
outgoing settings would not be checked. This also helps with
determining if a certificate exception was for the incoming or
outgoing server, which is needed if the user decides to add the
certificate to the keystore.
The commit that introduced those notifications also introduced a rather
... interesting design pattern: The CertificateValidationException
notified the user of its pure existance - it's no longer a 'message'
only, but defines policy. As this is more than unusual, replace this
pattern by the MessagingController treating
CertificateValidationException specially when accessing remote folders.
Also make clear which account failed when constructing the notification.
With this fix, a CertPathValidatorException or CertificateException will
create a "Certificate error: Check your server settings" notification
in the status bar. When the user clicks on the notification, they are
taken to the appropriate server settings screen where they can review their
settings and can accept a different server certificate.
Make the mTopView a ToggleScrollView. The only consumer is currently the MessageView, which uses a ToggleScrollView anyway. This should make it easier to reuse the anti-scrolling features in ToggleScrollView for ListView later on.
- Added AUTOMATIC as a new authentication method that will automatically choose the best authentication method (basically old behavior with CRAM_MD5). All other options will now enforce the selected authentication method.
- Added LOGIN as selectable option.
- Cleaned up code so strings to the different authentication methods are only defined once.
- Created "controller" and "mail.filter" package
- Moved a lot of classes to new/other packages
- Removed unused classes: NoSuchProviderException, MessageDateComparator
Fixes Issue 1278
Fixes Issue 119
Fixes Issue 1077
Fixes Issue 1238
Worked performed by danapple0 and cketti in
https://k9mail.googlecode.com/svn/k9mail/branches/issue1116
Add support for most batch ops (except move and copy) in search
results. Add support for batch move and copy on real folders.
Increase efficiency of bulk IMAP moves and copies by doing as multiple
UID operations.
Eliminated serialization of Account objects.
Provide up-references in useful places to make all future code cleaner
and more efficient.
Fixed a bunch of draft handling
Merged from issue1116 branch, except for Account.java, which was
copied wholesale. Account.java was manually merged in issue1116
branch at r1489
svn merge -r 1459:1489 https://k9mail.googlecode.com/svn/k9mail/branches/issue1116 .
cp ../issue1116/src/com/fsck/k9/Account.java src/com/fsck/k9/Account.java
r51837@31b (orig r127): ismarc31 | 2008-11-10 19:10:50 -0500
Experimental branch for Exchange WebDAV support
r51838@31b (orig r128): ismarc31 | 2008-11-10 19:24:52 -0500
Initial proof-of-concept code for WebDav support
r51839@31b (orig r129): ismarc31 | 2008-11-10 22:02:37 -0500
Fixed a couple of migration issues and enabled WebDav as a mail type
r53269@31b (orig r132): ismarc31 | 2008-11-21 21:55:55 -0500
Mostly rewritten class and organization. Better implementation of message fetching.
Consolidated response parsing. Removed a large number of redundant calls. There is still
some unused functions needing cleaning up, and some unimplemented actions
r53338@31b (orig r133): ismarc31 | 2008-11-22 16:50:02 -0500
Removed more redundant and unused calls. Implemented checking read status
r53453@31b (orig r134): ismarc31 | 2008-11-24 20:13:24 -0500
Added support for marking messages as read.
r53454@31b (orig r135): ismarc31 | 2008-11-24 22:04:04 -0500
Added support for deleting messages server side
r53455@31b (orig r136): ismarc31 | 2008-11-25 01:32:19 -0500
Improved flag setting functionality, do bulk HTTP request instead of lots of little ones
r53589@31b (orig r138): young.bradley | 2008-11-29 16:18:25 -0500
Missing some ports (webDavPorts); this causes an array index out of bounds exception when anything other than "None" or "SSL (Optional)" are selected.
Adding the three additional ports solves this issue.
r53590@31b (orig r139): young.bradley | 2008-11-30 00:47:42 -0500
Initial support for sending via WebDav
r53591@31b (orig r140): ismarc31 | 2008-11-30 20:12:41 -0500
Fix for display names being URL Encoded for folders. Initial support of Uid Hashmaps instead
of plain arrays.
r53592@31b (orig r141): ismarc31 | 2008-11-30 21:46:06 -0500
Fix to constructor of HttpGeneric(final String uri). URLs returned from Exchange aren't
always fully encoded, this fixes the encoding before creating the method.
r53593@31b (orig r142): ismarc31 | 2008-12-01 02:22:16 -0500
Completed support for using hashmaps instead of arrays for indexing urls to emails and read
status. Delete is safe again and read status is correct the first time through.
r53594@31b (orig r143): ismarc31 | 2008-12-01 22:20:50 -0500
Fix for double-Inbox display issue. Removed volumous amounts of Log.d messages.
r53644@31b (orig r157): young.bradley | 2008-12-04 15:14:28 -0500
Fix for wildcard certificates (e.g. issued to *.example.com). Only checking the
trust of the certificate itself, since apparently the full chain causes it to
not work.
r53765@31b (orig r161): ismarc31 | 2008-12-06 18:55:08 -0500
Implemented new functionality for pulling message envelope. Uses a WebDAV call for all messages rather than parsing the stream. Message size is properly set now as well.
r54055@31b (orig r163): jessev | 2008-12-06 19:28:24 -0500
* merge fixes
