iequidoo 3178308c14 BREAKING: Remove "vc-contact-confirm-received", "vg-member-added-received" messages from Securejoin protocol (#3836)
They are an overkill and do not solve any problem. Also they aren't documented anywhere. And all
necessary tests were added before and they work w/o the removed code.

AFAIU, they were added for Alice (joiner) to be sure that Bob (joinee) has Alice two-way verified,
i.e. Bob can add Alice to other verified groups because Bob knows that Alice trusts them. But that
means Alice should retry sending vc-contact-confirm/vg-member-added messages until getting
*-received message from Bob. But then better let Bob retry sending *-auth-required until getting
vc-contact-confirm/vg-member-added from Alice. And if Alice sees no more retries from Bob, either
Bob has got vc-contact-confirm/vg-member-added from Alice or there are communication problems. But
the latter can't be solved anyway by adding extra messages to the protocol. Note that there are no
retries currently, instead we rely on that Bob will eventually receive a message from Alice and thus
know that Alice verified them. But i could miss some details why they were added, so just in case,
citing from #3836:

    @iequidoo: Btw, can somebody explain the purpose of
    vg-member-added-received/vc-contact-confirm-received messages in the protocol? They look
    excessive and for me it's like a try to solve that problem with two friends that want to meet
    and drink some beer but only if each of them is sure that their beermate is also going to the
    meeting :) Even if Bob didn't receive vg-member-added message (e.g. because of mail delivery
    problems), we can consider Bob joined -- Bob can try sending messages to the group and that must
    work afaiu.

    @flub: Yes, this is a weird state. It is currently the difference between an internal state
    "un-idirectional verified" and the exposed state "bi-directional verified". The latter (bi-)
    means both know that both have each other verified, in the former (uni-) only one of them knows
    this and the other hasn't figured this out yet.

    IIRC the last time this was discussed the revelation (at least to me) was that the main
    practical difference between these two is that bi-directional allows you to add the other person
    to a verified group, while if you only have them uni-directional verified you can not do they
    since they don't trust you enough (IIRC, there should be a cryptpad somewhere with this written
    down).

    @link2xt: When Bob receives vc-auth-required, he already has Alice one-way verified. When Alice
    receives vc-request-with-auth, she has Bob two-way verified (she has verified Bob's key and she
    know Bob has verified her), but Bob still does not know about this. When Bob receives
    vc-contact-confirm (or vg-member-added) he sets Alice state to "two-way verified".

    The question is what happens if vc-contact-confirm/vg-member-added is lost. In this case Alice
    has Bob two-way verified, while Bob has Alice only one-way verified. Because of this, Bob cannot
    safely add Alice to any verified group, because Bob thinks maybe Alice has not received
    vc-request-with-auth and has Bob completely unverified. However, Alice still can add Bob to
    verified groups and if Bob later receives any message from Alice in a verified group, he sets
    Alice to two-way verified, so eventually both Alice and Bob converge to a two-way verified
    state. This is not how it is currently implemented, but this was the idea during the discussion
    with @flub and @missytake.

    But vg-member-added-received/vc-contact-confirm-received is an overkill and can be removed IMO,
    it does not solve any problem.
2023-04-28 14:20:54 -04:00
2023-04-24 22:31:17 +00:00
2023-04-24 22:31:17 +00:00
2023-04-24 22:31:17 +00:00
2023-04-18 18:54:41 +00:00
2023-04-24 22:31:17 +00:00
2023-04-24 22:31:17 +00:00
2023-04-24 22:31:17 +00:00
2023-04-24 22:31:17 +00:00
2022-01-13 11:11:50 +01:00

Delta Chat Rust

Deltachat-core written in Rust

Rust CI

Installing Rust and Cargo

To download and install the official compiler for the Rust programming language, and the Cargo package manager, run the command in your user environment:

$ curl https://sh.rustup.rs -sSf | sh

On Windows, you may need to also install Perl to be able to compile deltachat-core.

Using the CLI client

Compile and run Delta Chat Core command line utility, using cargo:

$ RUST_LOG=deltachat_repl=info cargo run -p deltachat-repl -- ~/deltachat-db

where ~/deltachat-db is the database file. Delta Chat will create it if it does not exist.

Optionally, install deltachat-repl binary with

$ cargo install --path deltachat-repl/

and run as

$ deltachat-repl ~/deltachat-db

Configure your account (if not already configured):

Delta Chat Core is awaiting your commands.
> set addr your@email.org
> set mail_pw yourpassword
> configure

Connect to your mail server (if already configured):

> connect

Create a contact:

> addcontact yourfriends@email.org
Command executed successfully.

List contacts:

> listcontacts
Contact#10: <name unset> <yourfriends@email.org>
Contact#1: Me √√ <your@email.org>

Create a chat with your friend and send a message:

> createchat 10
Single#10 created successfully.
> chat 10
Single#10: yourfriends@email.org [yourfriends@email.org]
> send hi
Message sent.

If yourfriend@email.org uses DeltaChat, but does not receive message just sent, it is advisable to check Spam folder. It is known that at least gmx.com treat such test messages as spam, unless told otherwise with web interface.

List messages when inside a chat:

> chat

For more commands type:

> help

Installing libdeltachat system wide

$ git clone https://github.com/deltachat/deltachat-core-rust.git
$ cd deltachat-core-rust
$ cmake -B build . -DCMAKE_INSTALL_PREFIX=/usr
$ cmake --build build
$ sudo cmake --install build

Development

# run tests
$ cargo test --all
# build c-ffi
$ cargo build -p deltachat_ffi --release

Debugging environment variables

  • DCC_MIME_DEBUG: if set outgoing and incoming message will be printed

  • RUST_LOG=deltachat_repl=info,async_imap=trace,async_smtp=trace: enable IMAP and SMTP tracing in addition to info messages.

Expensive tests

Some tests are expensive and marked with #[ignore], to run these use the --ignored argument to the test binary (not to cargo itself):

$ cargo test -- --ignored

Fuzzing

Install cargo-bolero with

$ cargo install cargo-bolero

Run fuzzing tests with

$ cd fuzz
$ cargo bolero test fuzz_mailparse --release=false -s NONE

Corpus is created at fuzz/fuzz_targets/corpus, you can add initial inputs there. For fuzz_mailparse target corpus can be populated with ../test-data/message/*.eml.

To run with AFL instead of libFuzzer:

$ cargo bolero test fuzz_format_flowed --release=false -e afl -s NONE

Features

  • vendored: When using Openssl for TLS, this bundles a vendored version.
  • nightly: Enable nightly only performance and security related features.

Update Provider Data

To add the updates from the provider-db to the core, run:

./src/provider/update.py ../provider-db/_providers/ > src/provider/data.rs

Language bindings and frontend projects

Language bindings are available for:

The following "frontend" projects make use of the Rust-library or its language bindings:


  1. Out of date / unmaintained, if you like those languages feel free to start maintaining them. If you have questions we'll help you, please ask in the issues. ↩︎

Description
Chatmail Rust Core library, used by Android/iOS/desktop chatmail apps, bindings and bots 📧
Readme MPL-2.0 105 MiB
Languages
Rust 74.4%
Tcl 9.1%
Python 8.8%
C 4.9%
DIGITAL Command Language 1.1%
Other 1.7%