Filter out control characters (U+0000 to U+001F) from outgoing
messages, as they are illegal in XML 1.0 (except for \t, \n, and \r).
This prevents XMPP servers from closing the connection when such
characters are accidentally or intentionally included in a message.
Fixes: https://github.com/profanity-im/profanity/issues/1437
Autocompletion failed for nicknames using non Latin scripts. We used
`g_str_to_ascii`, which replaces characters it cannot transliterate with
'?', leading search failures and false matches between different
scripts.
Now we do:
Use `g_utf8_casefold` for case-insensitive UTF-8 comparison. This
ensures that like 'Σ' correctly match 'σ' across all Unicode scripts,
providing correct results for non English nicknames.
If we don't fine anything typing a base ASCII character matches an
accented one (typing `e` matches `è`). This pass uses `g_str_to_ascii`
followed by `g_ascii_strdown` for comparison. It is now restricted to
run if the search string itself is valid ASCII, preventing the
"everything matches '?'" bug in non Latin scripts.
Autocomplete items are sorted using `strcmp`. `g_utf8_collate` provides
linguistical ordering for a specific language. But its behavior is
locale dependent and undefined when comparing strings from different
scripts. `strcmp` does byte-wise ordering that correctly follows Unicode
code order for UTF-8 strings.
Modify omemo_set_device_list to check against the persistent
known_devices.txt file before notifying the user. This prevents
false-positive security alerts on every restart for devices
that have already been registered and trusted.
Check against the persistent known_devices.txt file before notifying
the user. This ensures that "New OMEMO device" alerts are only shown
for devices that are truly new to this client.
Ref: ce9b5140d
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>
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.
When targeting a specific preference (`/time console off`)
the loop would continue to iterate through the remaining
categories after finding and applying the setting.
Because subsequent items would not match, it always resulted in
"invalid usage" printed as well after the success message.
The /connect command supports several optional parameters
server, port, tls, and auth.
This was implemented in ac410445af but
this change in the command definitions probably were forgotten.
Fix several issues in cmd_ac_complete_filepath:
* Prevent a segfault when input is empty.
* Fix a double free where acstring was managed by both auto_gchar and GArray.
* Fix a memory leak when reassigning inpcp during quote stripping.
* Restore the ability to cycle through files on repeated TAB presses by
caching the last input and skipping updates if the input is already a
known completion.
* Preserve user input style (e.g. ~, ./) in autocompletion strings to
ensure matches are correctly displayed and filtered.
Bug got introduced when "cleaning" code with new compiler flags and
sanitizers: aec8e48268.
Add unit tests so this doesn't happen again.
Before that commit we didn't use the static variable but used
autocomplete_update instead. Now we avoid redundat updates and preserve
the state across tab presses. We should look at this again later.
Fix https://github.com/profanity-im/profanity/issues/2098
Only handle self-presence for rooms we are actively managing.
Earlier we blindly react to any self-presence
stanza by calling 'ui_room_join'.
The join could have been initiated by another client or an external
Gateway. In the case of #731 this was Slack.
I remember that more people reported this kind of bug in our MUC.
We then would open a window and the nick would be (null) because we
don't have any nickname for that room set.
So only react on self-presence if we manage the MUC.
Other XMPP clients do the same.
Fix https://github.com/profanity-im/profanity/issues/731
When an OMEMO bundle is received with an empty <prekeys/> element,
`prekeys_list` remains empty. In omemo_start_device_session(),
performing a modulo operation on the length of an empty list
(0) triggered a SIGFPE (Floating point exception).
torsocks likely affected the network environment where such empty
or incomplete bundles could be intercepted.
Fix https://github.com/profanity-im/profanity/issues/1997
Simplify how field values are updated and ensure memory is correctly
managed.
The previous implementation relied on manual manipulation of the
GSList internal `data` member and only handled cases where a field
had zero or one existing value.
The function now correctly handles fields that may
already contain multiple values by using 'g_slist_free_full' to
clear the entire list and its contents before setting the new
value.
Adding an explicit NULL check for 'input' at the start of
cmd_ac_complete to prevent a potential crash and resolve
a GCC static analyzer warning.
Quirk Explanation:
The analyzer found a "deref-before-check" warning for:
`if ((strncmp(input, "/", 1) == 0) && (!strchr(input, ' ')))`
The analyzer interpreted 'strchr(input, ' ')' as a point where the
validity of 'input' is being questioned (a "check"), even though it is
actually checking the return value. This is due to GCC's internal model
of certain standard string functions having a 'nonnull' attribute or
being categorized as pointer "interrogations" in its state machine.
Because 'strncmp' dereferences 'input' earlier in the same line, the
analyzer saw a logical contradiction: "You treat it as safe in strncmp,
but then you call a function (strchr) that 'requires/checks' it to be
safe, implying you weren't sure."
