Largest change comes from removal of u64 and usize serialization
in rusqlite 0.38.0.
It is possible to enable it back with `fallible_uint` feature
as suggested in https://github.com/rusqlite/rusqlite/pull/1732,
but there is a good reason for this change
as it may result in unexpected failures when
trying to store u64 integers that don't fit in i64,
so I don't enable it back.
With this change conversions between i64 and u64 are explicit.
Using less `usize` is generally good as its size
differs on 32-bit platforms that are rarely tested
but still supported and we have changes that reduce its usage
such as 0defa117a0,
014d2ace76 etc.
Users downgrading to UIs that load legacy config values is unlikely,
and cannot work correctly with multiple transports.
BREAKING CHANGE: core does not set deprecated config values `addr`, `mail_pw` etc. Use `list_transports()` API instead.
This adds two tests for rendering unencrypted messages.
As a follow-up to,
https://github.com/chatmail/core/pull/8543#issuecomment-5207509885, I
would like to make sure that sensitive headers don't go into unencrypted
messages. While looking into this, I noticed that we don't have any
tests at all yet that test how exactly an unencrypted message is
rendered, only for specific parts.
Right now, we're sending `Chat-Disposition-Notification-To:
alice@example.org` in unencrypted messages, I think it should be
removed, I'll make a follow-up PR with a whitelist of allowed
unencrypted headers.
We don't look at the address in OPENPGP4FPR QR codes anymore.
If we cannot find a contact by fingerprint,
then we return an error without trying to look up
the contact by address.
Scanning OPENPGP4FPR can now only return FprOk
if matching key-contact is found, or an error.
BREAKING CHANGE: removed DC_QR_FPR_WITHOUT_ADDR and DC_QR_FPR_MISMATCH constants from CFFI
BREAKING CHANGE: removed FprWithoutAddr and FprMismatch variants from JSON-RPC QrObject returned by check_qr
this PR ensures blocked contacts or email contacts never get some
special treatment in the UI
- showing email contacts as recently seen (so with a dot) or as old is a
bit weird, this is not what is expected for email. also, the line for
"old" might be used to show the address
- for blocked contacts, this is mainly about the list of blocked
contacts - there, we do not want to higlight the contact somehow
targets https://github.com/chatmail/core/issues/8731
Fix https://github.com/chatmail/core/issues/8606
"Member added" messages in channels clutter the UI because sometimes, a
lot of recipients join, and it is not that interesting for the channel
owner who joined when exactly. Also, the correct string would be "XY
subscribed to your channel", but it seems easier and better to just
remove these messages.
There are 3 places in the code that can add a member to a channel:
- `add_contact_to_chat_ext()`, which is called during securejoin
- Seeing a member-addition message from our own second device in
receive_imf
- A sync message telling us about a member addition which we missed
Fixes https://github.com/chatmail/core/issues/8692: Now the user does
not get notifications when a blocked contact reacts to some message.
What this PR does not change is what happens when being in a group with
a blocked contact; it only fixes this obvious bug.
I checked that the test fails without the fix.
this PR avoids marking a message as being failed if we already received
an read receipt for it.
background: esp. with multi relay it will easily happen that we get some
NDN for some relays. this does not mean the message at a whole was
failing, esp. if we got a read receipt (MDN) before
with https://github.com/chatmail/core/pull/8722 we do no longer process
NDN in groups, so the change of this PR affects one-to-one chats only
reported by bjoern while testing the branch on iOS: the background addition
would start fast enough to still show up in the configure-progress bar
of the initial onboarding screen. This commit should fix that.
Closes#8693 and supsersedes #8707 from which the API
and some overall shape of this commit is inspired.
UIs call `init_transports(None)` or `init_transports(qr)`
to initialize a first transport on the fresh profile,
with more transports added in the background later.
`list_transports()` should be used instead.
Previously `addr` field might have even not correspond to any transport
as it was `Config::Addr` and not `Config::ConfiguredAddr`.
BREAKING CHANGE: list_transports() should be used instead.
this PR adds a hack to allow relay operators
to differ between manually created relays and autorelays.
this is a precaution in case unexpected things happen when introducing
autorelay; relay operators then can deny creation on `password_len ==
23`, without shutting down manual creation completely.
depeding on final initTransport() is done,
it may still be that the first created relay is marked as being manual,
but that seems fine.
`password_len` of the autmatically generated password was chosen as
there is otherwise not much data sent -
chatmail avoids visible data and metadata everywhere.
this hack is about to be removed again asap,
once we have some experiences with multi relay.
---------
Co-authored-by: l <link2xt@testrun.org>
UIs should use display name everywhere and avoid displaying email addresses.
BREAKING CHANGE: dc_contact_get_name_n_addr() CFFI is removed
BREAKING CHANGE: JSON-RPC contact objects don't have nameAndAddr field anymore
No changes except that smtp::is_queue_empty is renamed into smtp::queue::is_empty,
mimefactory::QueuedEncryption is renamed into smtp::queue::Encryption
and mimefactory::QueueSideEffects is renamed to smtp::queue::SideEffects.
mimefactory module does not know anything about smtp2 table anymore.
This is mostly needed to fix flaky
tests/test_something.py::test_is_sending_finished
by making sure that is_sending_finished() return false
once we got an event that message was sent.
This removes the last usages of the deprecated `is_chatmail` and
no `XCHATMAIL` IMAP capability is read anymore.
UIs are not using it for a longer time anymore.
The self-reporting statistics now set `is_chatmail` field to
`true`: all transports have relay-typical metadata
`false`: at least one doesn't
`null`: we don't know
BREAKING CHANGE: `is_chatmail` is no longer a known config key.
don't use `is_chatmail` for determining whether to delete messages on the server:
whether a downloaded message may be dropped from the relay
depends on whether another device still needs it (BccSelf)
and on whether plaintext mail is allowed (ForceEncryption).
Also adds tests and docs to respective functions,
clarifying background fetching behaviour and the `ACCOUNTS_BACKGROUND_FETCH_DONE` event,
that came up in questions/discussions with UI devs lately.
mark_seen=True is the default and translates to fetching BODY
of the message. mark_seen=False translates to fetching BODY.PEEK
that is described in IETF RFC 3501 as
"An alternate form of BODY[<section>] that does not implicitly set the \Seen flag."
It is unexpected unless you know this detail of IMAP protocol already,
but this is not going to be fixed in imap_tools: <https://github.com/ikvk/imap_tools/issues/179>
"addr" is already deprecated and its default value was using "configured_addr".
We want to get rid of "configured_addr" too, but users should at least
not access it through deprecated config.
"Inconsistent key state" referred to acpeerstates table row
with different Autocrypt and verified keys.
Since v2 and introduction of key contacts it is not possible for a contact
to have inconsistent key state, so this translates to having
two contacts with the same email address but different keys.
link2xt
Hocuri
biørn
holger krekel