This factors out all MDN-related code that was previously inside `MimeFactory`
into a `mimefactory::mdn` function that constructs `QueuedMail` directly,
similarly to `mimefactory::keyupdate_message`.
Removing MDN-related code from MimeFactory also means that MimeFactory only handles non-MDN messages now
and we don't have to `match` on `MimeFactory.loaded` everywhere to access `msg` and `chat`.
Unlike `MimeFactory::from_mdn`, `mimefactory::mdn` does not need to fill `MimeFactory.from_addr`.
This removes one `get_primary_self_addr()` call. `mimefactory::mdn` also does not need to fill
various fields that are never used for MDNs such as `past_members`.
It looks like the function is only called for File and Image viewtypes,
so there is no way to get into the Sticker branch
that checks the corners for transparency.
A join request is sent to every relay of an inviter, but the answering
inviter device only deleted the copy it downloaded. Another device of the inviter
fetching a different relay later answered the request again, re-adding
members who had left or been removed in the meantime.
this PR makes it easier to spot unwanted "add second device" actions, if
the unlocked device is left unattended and/or a system lock is not in
place (so cannot be checked directly before doing the "add second
device" action).
already today, the sending device gets the message "ℹ️ Profile
transferred to your second device", which, however, can be deleted.
with this PR, if the message is deleted soon after the transfer, it
first looks as if this was successful. however, the message is re-added
later, at the first housekeeping at least an hour after the transfer.
deleting the message after that is final, so users can still get rid of
it.
It is clear that this does not catch all eventualities, it is
best-effort. e.g. it is known that subsequent "add second device"
attempts remove checks of previous ones.
First line of defense is device locking and asking for secret explicitly
before adding a second device.
previous discussions about that at
https://github.com/chatmail/core/issues/4303
Paths in deltachat.pc are passed via env variables to build.rs. With
this fix, the pc will be regenerated if these env variables change.
This came up when building via CMake: the paths depend on
CMAKE_INSTALL_PREFIX, if the CMAKE_INSTALL_PREFIX changes during a
reconfigure, deltachat.pc should have the corresponding paths adjusted.
This PR fixes how addresses in securejoin invite codes (i.e. QR codes
and invite links) are percent-encoded.
Before this PR,
- `@` in the addresses was percent-encoded. This makes the invite code
harder to read, and is not necessary; at least, every software we tested
correctly handled links that contain `@` (Signal, WhatsApp, Telegram,
Thunderbird, Delta Chat on Android, iOS, and Desktop)
- _But_, the first address in the `r=` parameter of a securejoin link
was not percent-encoded at all. This was a sneaky bug caused by using
the `reduce` function; I always find it hard to follow code that uses
`reduce` (and similar functions like `fold`), and apparently others have
the same problem since neither @j-g00da nor @link2xt noticed the problem
when implementing & reviewing the PR that introduced the bug.
With this PR:
- `@` is allowed in addresses in securejoin invite codes
- all addresses are percent-encoded
- `reduced` is not used anymore
---------
Co-authored-by: l <link2xt@testrun.org>
Stop logging the time migration takes
and don't log anything when migration runs on a fresh database
and only creates empty tables.
Without these changes every time profile is created,
the following info lines are logged:
src/sql/migrations.rs:35: Starting key-contact transition.
src/sql/migrations.rs:82: Not yet configured, no need to migrate key-contacts
src/sql/migrations.rs:1942: key-contacts migration took 1.143721ms in total.
This is not a correct way to reset the database, it does not even clear the transports table
so account stays configured. If someone needs a fresh database, then REPL should be restarted
with a new path.
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.
dependabot[bot]
link2xt
holger krekel
biørn
d2weber
missytake
Hocuriandl