fix: do not save "Automatic" into configured_imap_certificate_checks

configured_imap_certificate_checks=0 means
accept invalid certificates unless provider database
says otherwise or SOCKS5 is enabled.
It should not be saved into the database anymore.

This bug was introduced in
<https://github.com/deltachat/deltachat-core-rust/pull/5854>
(commit 6b4532a08e)
and affects released core 1.142.4, 1.142.5 and 1.142.6.

Fix reverts faulty fix from
<https://github.com/deltachat/deltachat-core-rust/pull/5886>
(commit a268946f8d)
which changed the way configured_imap_certificate_checks=0
is interpreted and introduced problems
for existing setups with configured_imap_certificate_checks=0:
<https://github.com/deltachat/deltachat-core-rust/issues/5889>.

Existing test from previous fix is not reverted
and still applies.
Regression test is added to check that
configured_imap_certificate_checks
is not "0" for new accounts.

deltachat-rpc-client/tests/test_something.py

@@ -635,3 +635,24 @@ def test_get_http_response(acfactory):
     http_response = alice._rpc.get_http_response(alice.id, "https://example.org")
     assert http_response["mimetype"] == "text/html"
     assert b"<title>Example Domain</title>" in base64.b64decode((http_response["blob"] + "==").encode())
+
+
+def test_configured_imap_certificate_checks(acfactory):
+    alice = acfactory.new_configured_account()
+    configured_certificate_checks = alice.get_config("configured_imap_certificate_checks")
+
+    # Certificate checks should be configured (not None)
+    assert configured_certificate_checks
+
+    # 0 is the value old Delta Chat core versions used
+    # to mean user entered "imap_certificate_checks=0" (Automatic)
+    # and configuration failed to use strict TLS checks
+    # so it switched strict TLS checks off.
+    #
+    # New versions of Delta Chat are not disabling TLS checks
+    # unless users explicitly disables them
+    # or provider database says provider has invalid certificates.
+    #
+    # Core 1.142.4, 1.142.5 and 1.142.6 saved this value due to bug.
+    # This test is a regression test to prevent this happening again.
+    assert configured_certificate_checks != "0"

src/configure.rs

@@ -27,7 +27,7 @@ use crate::config::{self, Config};
 use crate::context::Context;
 use crate::imap::{session::Session as ImapSession, Imap};
 use crate::log::LogExt;
-use crate::login_param::{LoginParam, ServerLoginParam};
+use crate::login_param::{CertificateChecks, LoginParam, ServerLoginParam};
 use crate::message::{Message, Viewtype};
 use crate::oauth2::get_oauth2_addr;
 use crate::provider::{Protocol, Socket, UsernamePattern};
@@ -280,7 +280,21 @@ async fn configure(ctx: &Context, param: &mut LoginParam) -> Result<()> {
         param_autoconfig = None;
     }
 
-    let strict_tls = param.strict_tls();
+    let user_strict_tls = match param.certificate_checks {
+        CertificateChecks::Automatic => None,
+        CertificateChecks::Strict => Some(true),
+        CertificateChecks::AcceptInvalidCertificates
+        | CertificateChecks::AcceptInvalidCertificates2 => Some(false),
+    };
+    let provider_strict_tls = param.provider.map(|provider| provider.opt.strict_tls);
+    let strict_tls = user_strict_tls.or(provider_strict_tls).unwrap_or(true);
+
+    // Do not save `CertificateChecks::Automatic` into `configured_imap_certificate_checks`.
+    param.certificate_checks = if strict_tls {
+        CertificateChecks::Strict
+    } else {
+        CertificateChecks::AcceptInvalidCertificates
+    };
 
     progress!(ctx, 500);
 

src/login_param.rs

@@ -265,7 +265,9 @@ impl LoginParam {
             | CertificateChecks::AcceptInvalidCertificates2 => Some(false),
         };
         let provider_strict_tls = self.provider.map(|provider| provider.opt.strict_tls);
-        user_strict_tls.or(provider_strict_tls).unwrap_or(true)
+        user_strict_tls
+            .or(provider_strict_tls)
+            .unwrap_or(self.socks5_config.is_some())
     }
 }