Removing the UI notification in omemo_start_device_session to reduce
noise during /omemo start.
The information is still available in the debug logs.
And I think for existing sessions its just too much without value.
Ref: b20e3f1a
When sending OMEMO messages, we print a warning message for every
participant without a device ID on every single send:
```
Can't find a OMEMO device id for my@jid.org
```
This clutters the UI due to the high volume of repetitive information.
This is solved by tracking suppressed warnings within the window
structure. A warning for a specific JID and type is only shown once
per window context.
Suppression state is stored in the base ProfWin structure and managed
via helper functions (win_warn_needed, win_warn_sent). The state is
lazily initialized to save resources and automatically cleaned up when
the window is closed.
Warnings are explicitly reset when an OMEMO session is started or
ended to ensure users see fresh alerts when toggling encryption.
Instead of repeating the same pattern over and over, introduce a helper
function that either outputs a formatted timestamp if one is given as
argument or returns the current time if no argument is given.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
In the process of trying to bring down the time of sending an OMEMO
encrypted message I noticed that a lot of time was spent in generating the
random key and IV (~0.54s on my machine).
By changing this to a single call to `gcry_random_bytes_secure()` I have
been able to slash the time by 50% to ~0.27s.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
Instead of flushing the OMEMO store to disk after each operation, do it
only once after all recipients are processed.
A user reported a long delay between hitting enter on the keyboard and the
message being sent on the wire in an OMEMO-enabled group chat. This patch
hopefully improves this situation.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
It's not guaranteed that `log_database_get_limits_info()` returns a
non-NULL value or that `timestamp` is non-NULL.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
Synchronize theme_template with the current codebase by adding all
themeable preferences and color attributes that were previously
undocumented.
Remove 'wins.autotidy' option which is no longer used.
The idea is that we keep our DOAP file updated.
Then we always know which version of a XEP we implemented.
By running this script we can then find out if a new version of a XEP
came out.
And we can check whether we need to update our code to adhere to the
latest version or whether we can just version bump.
a26cdf386b / #2104 added OMEMO trust status to the
title bar, but it was being re-calculated on UI refresh.
Update only on certain operations (like `/omemo trust`, new device
discoveries and even incoming OMEMO messages for example).
Commit 81f92f1fe introduced a selective update mechanism to
_accounts_save() to prevent overwrites when running multiple instances
by only modifying the specific account being saved.
There was one mistake: the logic for adding a new
account was tied to the final iteration of a loop over
existing accounts.
When starting with an empty accounts file, the
loop never executes though.
We can call g_key_file_set_value() directly and don't need the loop
because this function will only modify one entry or add it if it doesn't
exist.
Add __attribute__((nonnull) hints to omemo_receive_message and
omemo_on_message_recv declarations to catch NULL arguments at
compiletime.
So we can set the error state unconditionally in the functions.
If an incoming OMEMO message failed to decrypt (due to missing session
keys or untrusted identities), Profanity would fall back to displaying
the raw XMPP body. This usually contained a generic string like "This
message is encrypted with OMEMO,".
We wrote the detailed reason in the debug logs but the user only saw the
fallback message and probably wondered *why* the message wasn't
displayed properly.
I'm unsure if we should display the fallback message as well though.
After typing `/omemo start` a user was not informed of what exactly
happens.
Profanity is fetching the device list and the key bundle for each
device. This happens asynchronously. It could be that it takes some time
and the user already starts typing a message, believing OMEMO is
working.
Now we print:
* Initiating OMEMO session..
* Fetching device list and key bundles
* OMEMO session ready
So the user understands much better the current situation.
The /omemo fingerprint command provided a list of all keys ever
seen for a contact but did not indicate which keys were currently "active"
(present in the latest server device list). This made it difficult for users
to identify which fingerprints actually required verification to fix
encryption issues.
Users can now easily distinguish between devices currently in use and
historical keys that no longer matter.
When encryption fails users can immediately see which "active" key is
"untrusted," allowing them to verify the correct fingerprint fast.
Function `omemo_is_device_active` will check if a fingerprint belongs
to a device currently announced by the contacts server.
When OMEMO encryption failed due to untrusted devices, the
user was presented with a generic error message. This made it difficult
to identify which specific fingerprints were causing the issue, forcing
users to manually hunt for untrusted keys using /omemo fingerprint.
New function `omemo_get_jid_untrusted_fingerprints` to specifically
identify unverified identities for a contact.
`omemo_on_message_send` will now catch encryption failures and
explicitly list the untrusted fingerprints in the chat window.
Previously, Profanity silently updated OMEMO device lists and identity
caches in the background. This often led to confusion when a contact
added a new device, as encryption or decryption would eventually fail
due to untrusted keys without any prior warning to the user.
The `notifying` flag will distinguish between initial data loading and
realtime discovery.
We now print a message both when a contact publishes a new device ID or
when a new fingerprint is discovered.
Previously the titlebar only showed [OMEMO], regardless of whether the
active session contained untrusted devices. This forced users to manually
run /omemo fingerprint to check the security status of their conversation,
making it difficult to know at a glance if a session was truly secure.
New function `omemo_is_jid_trusted()` to check if all active devices for a JID are trusted.
Update chat and MUC titlebar to display [trusted] or [untrusted] tags when an OMEMO session is active.
Not sure if MUC makes sense here?
GKeyFile parses ini-like config files. So the characters '[', ']',
and '=' cannot be used.
We will replace them with '_' now.
This bug was found when a user wanted to connect to an IPv6 address (user@[ipv6:address]).
One problem could be that we get duplicate account names with they would
use one of those 3 characters. But I consider this very unlikely.
Fix https://github.com/profanity-im/profanity/issues/2103
Make jid_is_valid() allow JIDs ending with a slash (`user@domain/`).
In these cases, the parser now treats the input as a Bare JID with no
resource part, rather than rejecting it as invalid.
We will then just get `user@domain`.
This one will need a localpart as well.
It should be used when we want to message a user for example.
While jid_is_valid() also returns TRUE for domain/server JIDs.
