There is a real risk of an active attack when connecting to non-.onion
servers over Tor, as bad Tor exit nodes are cheap to set up.
It's probably not needed for .onion domains, but we don't make an
exception for now.
This adds following settings:
- Socks5Enabled
- Socks5Host
- Socks5Port
- Socks5User
- Socks5Password
Currently http requests and dns requests are not getting executed as they currently can't get tunneled through socks5 proxy. Therefore gmail with oauth2 wont work through tor.
fix#2539
It's always a bit ambiguous which function should do set_err or set last_send_error, I used this rule here:
If some code returns Status::RetryLater, then it sets last_send_error, because Status::RetryLater means that the user won't see the error directly on the message (if we returned Status::Failed(Err(_)), then the message would be shown as failed to the user) Also, smtp_send always sets last_send_error because, well, sending just failed or succeeded.
Also, remove unused field pending_error.
See https://support.delta.chat/t/discussion-how-to-show-error-states/1363/10 <!-- comment -->
It turns out that it's pretty easy to distinguish between lots of states (currently Error/NotConnected, Connecting…, Getting new messages… and Connected). What's not that easy is distinguishing between an actual error and no network, because if the server just doesn't respond, it could mean that we don't have network or that we are trying ipv6, but only ipv4 works.
**WRT debouncing:**
Sending of EVENT_CONNECTIVITY_CHANGED is not debounced, but emitted every time one of the 3 threads (Inbox, Mvbox and Sentbox) has a network error, starts fetching data, or is done fetching data.
This means that it is emitted:
- 9 times when dc_maybe_network() is called or we get network connection
- 12 times when we lose network connection
Some measurements: dc_get_connectivity() takes a little more than 1ms (in my measurements back in March), dc_get_connectivity_html() takes 10-20ms. This means that it's no immmediate problem to call them very often, might increase battery drain though. For the UI it may be a lot of work to update the title everytime; at least Android is smart enough to update the title only once.
Possible problems (we don't have to worry about them now I think):
- Due to the scan_folders feature, if the user has lots of folders, the state could be "Connecting..." for quite a long time, generally DC seemed a little unresponsive to me because it took so long for "Connecting..." to go away. Telegram has a state "Updating..." that sometimes comes after "Connecting...".
To be done in other PRs:
- Better handle the case that the password was changed on the server and authenticating fails, see https://github.com/deltachat/deltachat-core-rust/issues/1923 and https://github.com/deltachat/deltachat-core-rust/issues/1768
- maybe event debouncing (except for "Connected" connectivity events)
fix https://github.com/deltachat/deltachat-android/issues/1760
* Remove sql::error submodule
Use anyhow errors instead.
* Remove explicit checks for open SQL connection
An error will be thrown anyway during attempt to execute query.
* Don't use `with_conn()` and remove it
* Remove unused `with_conn_async`
* Resultify markseen_msgs
if the past we had lots of crashes because of unexpected unwrap failures,
mostly related to string.
this commit avoids them eg. for string-conversions that may panic
eg. when encountering a null-byte or by logical programming errors
where an object is assumed to be set but is not under unexpected circumstances.
Previously, `dc_get_oauth2_access_token` accepted "flags" argument,
that actually had only one possible field: 0x1 == DC_REGENERATE.
This change replaces "flags" argument with single boolean argument
"regenerate".
Previously, logging macros (info! warn! error!) accepted integer
argument (data1), that was passed to callback function verbatim. In all
call sites this argument was 0.
With this change, that data1 argument is no longer part of macro
interface, 0 is always passed to callback in internals of these macros.
Without this change, when SMTP password is incorrect,
as_str(sock.error) is called with a null pointer,
and as_str panics.
Now it does not crash when the error is not set.
* refactor: safe sql access
* Clean up the worst rebase mistakes
* Some more progress on the rebase fallout and this branch
* upgrade and compile again
* cleanup from rebase
* example of how to prepare now
* rebase fixes
* add sql.query_map
* less preparation
* more improvements in sql code
* fix string truncation
* more prepare conversions
* most prep done
* fix tests
* fix ffi
* fix last prepares
* fix segfaults and some queries
* use r2d2 pool
* fix dc_job sql call, to reduce contention
* try newer rust
* No more vararg printing (drop dc_log_)
* ignore expected errors
* fix: uses exists instead of execute where needed
* fix: get_contacts logic was broken
* fix: contact creation
* test on 32bit linux
* ci: try running 32bit without cross
* undo 32bit tests
* refactor: rename dc_sqlite3 to sql
* fix: safer string conversions
* more string fixes
* try fixing appveyor build to 64bit
* chore(ci): hardcode target
* chore(ci): appveyor
* some cleanup work
* try fix darwin
* fix and improve sql escaping
* fix various bugs
* fix chat deletion
* refactor: cleanup config values and move to their own file
* refactor: move more methods onto the sql struct
* dont panic on failed state loading
* first round of cr
* one more cr fix
* stop using strange defaults
* remove unused escapes
The function does a cast and does not create a new objects. The
stdlib convention is to use to_*() for functions which return new
objects and as_*() for functions which keep referring to the same data
but using a different type. Follow that convention.
