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.
They were disabled in 171b6e73c9.
Enable the functional test suite and replaces the
dependency on libexpect with a custom solution.
The native solution allows for specific optimizations like automatic
ANSI code stripping, which is essential for reliable pattern matching in
an ncurses interface.
Custom PTY management via libutil provides full control over the process
lifecycle, resolving issues where tests would hang indefinitely.
We use forkpty from libutil.
Addiiotnally this commit implements automatic ANSI escape sequence
filtering to improve matching consistency.
This will get rid of the colors in matches. It's still something that we
need to think about more since basically we will not test out
color/theme system this way.
We also add non-blocking poll() and SIGKILL based teardown logic to
ensure clean test termination.
We added the functional tests to both autotools and meson.
They are only build when tests are enabled and stabber + libutil are
present.
Meson will print this out nicely in the summary.
Regards https://github.com/profanity-im/profanity/issues/789
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
Usually we point to the website. But honestly it's cumbersome for
developers to update the website. Let's decide later whether we remove
the section there or how we keep it in sync.
But for now let's just add a detailed build section here.
Especially since now we ship autotools *and* meson.
Also mention the convention that we use `build_run` as the meson build
dir. The quality script will depend on this.
Update the gh workflow to pin clang-format to version 21.
Mention the version we use in CONTRIBUTING.md.
And hint to the workflow file if we want to change it.
