Replace the hardcoded "me" stamp for outgoing messages that are
sometimes used with the value from PREF_OUTGOING_STAMP.
It was never implemented in all code paths. Like with receipts for
example.
Additionally fix the confusing description and variable names.
Ref: 2c003dd2 (Add /stamp feature)
Ref: 3a4cd7da (Broke the variables)
Fixes: https://github.com/profanity-im/profanity/issues/2125
Signed-off-by: Michael Vetter <jubalh@iodoru.org>
Disable the functional tests in the case of meson as well.
They don't seem to work in the CI or take too long.
This needs further investigation. For now let's run them locally and
before each release.
Signed-off-by: Michael Vetter <jubalh@iodoru.org>
This will result in smaller and cleaner tarballs for distributions to use.
Additionally it is a logical step towards moving fully to the Meson build system.
While the last release provided two tarballs (one generated with
Autotools and one with Meson), the next release will only provide a
Meson-generated tarball.
These attributes are respected by `git archive` and `meson dist` which
means they will take effect for the Meson generated tarballs and the
GitHub autogenerated tarballs as well.
As a consequence of switching to `meson dist`, pre-generated files like
`configure` will no longer be included in the tarballs. Users and
distributions that still wish to use the Autotools build system from
these tarballs will now need to run `./bootstrap.sh` or `autoreconf -fi`
themselves, which requires automake, autoconf, and libtool to be
installed.
Since many distributions are slowly dropping the usage of vendor
generated tarballs and are moving to checking out git tags this should
not be a problem.
Arch Linux is for example doing
`source=("git+https://github.com/user/project.git#tag=v1.2.3")` and
Debian has the `git-buildpackage` too. So both of them require require
autoreconf already.
Autotools support might be removed entirely in a future
release since I find them much easier to edit and maintain.
Instead of:
```
CI / Check coding style
CI / Check spelling
CI / debian | Autotools | unit | signal
CI / debian | Meson | unit+func | libomemo
CI / debian | Meson | unit+func | signal
CI / fedora | Autotools | unit | signal
CI / ubuntu | Autotools | unit | signal
Cygwin / cygwin-build
```
We will sort them into "Style", "Linux" and "Cygwin".
Triggered by unit tests. In Profanity itself the situation is probably
rarely happening. We would have to disconnect/exit after receiving
presence but before the roster arrives.
Locally valgrind is quiet. But on CI valgrind complains. This is due to
an older valgrind version which doesn't handle AVX2-optimized strings
properly. So we need to add it to the suppression file.
Have a better overview, we are interested in which tests are run, which
distro, which build system and which omemo backend.
debian | Autotools | unit+func | signal
debian | Meson | unit+func | signal
debian | Meson | unit+func | libomemo
fedora | Autotools | unit+func | signal
ubuntu | Autotools | unit+func | signal
Add support for <report-origin/> and <third-party/>.
When a server forwards a report to an administrator, the original reporter
(report-origin) and the offender (third-party) are preserved even
if the 'from' address is modified during forwarding.
Also display this information in case we receive a report.
Update `blocked_add` to use the `<body>` tag with the `jabber:client`
namespace when reporting spam, as specified in XEP-0377 Example 5.
Other report types continue to use the `<text>` tag.
Fixes: https://github.com/profanity-im/profanity/issues/1971
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
Allow sending byte sequences to the Profanity PTY without a newline.
Now we can simulate control characters, specifically the `TAB` key
(`\t`), to trigger autocompletion.
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>
