Cleanup of the conversion-safety warnings exposed by enabling
-Wconversion / -Wsign-compare in the previous commit, plus guard
clauses at the few places where unsigned arithmetic could actually
misbehave.
Build:
- configure.ac drops -Wno-error=conversion and
-Wno-error=float-conversion. Only -Wno-error=sign-conversion and
-Wno-error=sign-compare remain, gating the ~230 sign warnings
inherited from upstream that will be cleaned up in follow-ups.
Type / conversion fixes (no behaviour change):
- Length-like locals in command/cmd_ac.c, command/cmd_funcs.c,
pgp/gpg.c, tools/autocomplete.c, tools/parser.c and ui/mucwin.c
switched from int to size_t / glong (matching strlen /
g_utf8_strlen return type) so we no longer need an (int) cast and
loop counters / array sizes stay in their natural unsigned domain.
- g_timer_elapsed / GTimeSpan -> int casts in session.c, iq.c,
core.c, server_events.c, window.c.
- _win_print_wrapped: indent parameter and local curx/maxx switched
from size_t to int to match _win_indent / getcurx / getmaxx.
- Port casts (int -> unsigned short) at the libstrophe boundary in
connection.c and session.c, each preceded by
g_assert(port >= 0 && port <= UINT16_MAX) so the truncation is
documented at the call-site.
- curl_off_t / fread size_t results cast at usage in http_upload.c,
http_download.c, omemo/crypto.c.
- strtoul results cast to uint32_t in xmpp/omemo.c and omemo/omemo.c
where device/prekey IDs are genuinely 32-bit.
- config/color.c: fg/bg/palette indices switched to `short`
end-to-end (find_col, color_hash, find_closest_col,
_color_pair_cache_get, cache.pairs), so the ncurses init_pair
boundary needs at most one (short)i cast for the cache index. Also
TODO-noted: init_extended_pair is needed for >15-bit palettes.
- xmpp/avatar.c: float arithmetic explicitly casts its int operands.
- tests/functionaltests/proftest.c: read() result handling uses
size_t for the accumulator, _read_output returns ssize_t, and the
buffer-shift check happens before space subtraction so the
expression cannot underflow.
Real-risk guard clauses (the part that actually fixes bugs):
- src/ui/statusbar.c _tabs_width: `end > opened_tabs - 1` rewritten
as `end < opened_tabs` so opened_tabs == 0 no longer underflows.
- src/ui/statusbar.c _status_bar_draw_extended_tabs: the mirror
comparison rewritten as `end >= opened_tabs`.
- src/ui/statusbar.c status_bar_draw: replaced
`MAX(0, getmaxx - (int)_tabs_width)` with an explicit precheck
before subtraction.
- src/omemo/omemo.c prekey selection: prekey_index is now uint32_t
and randomized into an unsigned buffer, so modulo with prekeys_len
cannot yield a negative index for g_list_nth_data.
- src/omemo/crypto.c omemo_decrypt_func: PKCS#5/PKCS#7 unpadding
reads `plaintext[plaintext_len - 1]`, which would underflow on a
malformed empty ciphertext and read past the heap buffer. Reject
plaintext_len == 0 before the padding peek and validate the
padding byte against the buffer length before the unpad loop.
Initialise plaintext = NULL so the early `goto out` cannot free
uninitialised memory.
- src/ui/inputwin.c (4 mbrlen sites) and src/ui/window.c
_win_print_wrapped: mbrlen() returns 0 for the null wide
character. The existing checks rejected (size_t)-1 / -2 but
treated 0 as a valid step, so the surrounding loops would either
advance by SIZE_MAX (i += ch_len - 1) or spin in place
(word_pos += 0 forever). Add `|| ch_len == 0` to each guard;
inside the spell-check word-emission loop also fall back to a
one-byte advance.
- Defensive `len > 0 ? len - 1 : 0` prechecks at the strlen-based
g_strndup / loop sites in ui/console.c, plugins/c_api.c and
plugins/python_plugins.c.
Apply fixes, refactors and test additions requested by reviewer on PR #105.
Fixes:
- database: warn and notify user on duplicate archive_id instead of
silently debug-logging it (R05).
- database: add missing '[' in "[DB Migration]" log prefix (R06).
- xmpp/resource: NULL-out name/status after g_free to avoid double-free
via roster_list.c cleanup path (R09, R23).
- common: widen strtoi_range internal storage from int to long so that
values in (INT_MAX, LONG_MAX] are rejected as out-of-range instead of
being silently truncated on 64-bit platforms (R25).
Refactors:
- xmpp/message: extract _receive_omemo helper, removing three copies of
the OMEMO receive block in groupchat / MUC-PM / chat handlers (R04).
- omemo: flatten deeply nested device-list processing via guard-clause
continues (R11).
- tools/autocomplete: merge two nested ifs into a single && condition
(R13).
- ui/titlebar: extract _show_trust_indicator and inline _wprintw_withattr
wrapper, collapsing three near-identical trust-indicator blocks (R22).
- config/tlscerts: drop _checked_g_strdup wrapper; g_strdup is
NULL-safe per glib documentation (R19).
- ui/inputwin: use auto_gchar for spellcheck word instead of manual
g_free (R20).
- tools/editor: drop outdated "Deprecated synchronous" comment that
no longer matches the callback-based implementation (R28).
Tests:
- tests/command/cmd_ac: rename segfaults_when_empty ->
no_segfault_when_empty; expand cycling coverage to three files plus
backward SHIFT-TAB traversal (R16, R17).
- tests/common: add strtoi_range overflow/underflow and strtol-parsing
consistency tests (R25).
- tests/xmpp/jid: add test for '@' inside resourcepart per RFC 6122
section 2.4 (R26).
Misc:
- xmpp/omemo: change omemo_error_to_string return type from char* to
gchar* for glib consistency (R01).
- subprojects/libstrophe: point wrap-git at our fork at
git.jabber.space/devs/libstrophe-gh (R24).
- RELEASE_GUIDE: drop "Updating website" section referring to an
upstream site that is not ours (R18).
Centralize heartbeat detection and have a function for error to string
mapping. So we don't need the same code in multiple handlers.
Signed-off-by: Michael Vetter <jubalh@iodoru.org>
Correctly handle OMEMO stanzas that contain a <header> but no <payload>.
These "Key Transport Messages" (heartbeats) are used by some clients
for session maintenance and establishing trust.
Ref: a2726b6a7 made the <payload> element mandatory in the parser.
Ref: 4d49c2b74 the bug became user-visible.
Fixes: https://github.com/profanity-im/profanity/issues/2129
Signed-off-by: Michael Vetter <jubalh@iodoru.org>
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.
Use a singleton `Jid` inside the connection instead of always re-creating
a `Jid` from the same string.
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
If we are not able to publish our own device list, we just ignored it.
This commit will show at least an error message and informs the user that this
device is currently not in the list of devices.
See Issue: #1538
Next task will be to handle the <precondition-not-met/> conflict properly.
The most loggings has been set to debug. Just in case of error / problem the
logging should be done with log-level ERROR or WARNING.
We will see later, which loggings should be switched to log-level INFO.
This improvement has been done to find OMEMO bugs.
See also: #1070#1530#1538
Use the following options in `omemo_bundle_publish()`:
- "pubsub#persist_items" = "true"
- "pubsub#access_model" = "open"
The same options are also used in Gajim.
I've tested this on two different servers. The bundle was successfully
added as a new PEP node. Test cases:
1. Normal use on my main account
2. Log in into a fresh tesst account on a different server
3. `/omemo clear_device_list`. In this case, the client(s) may have to
be restarted.
Note: In `_omemo_bundle_publish_result`, there's a route that is taken
when the bundle publish stanza failed. In this case, the node is
configured manually, i.e. the access_model is set to 'open'. I have
manually tested this case, but this case didn't naturally occur for me.
Note: The option "pubsub#max_items=max" is REQUIRED for the bundle
publication, as per XEP-0384. However, this is not done in other clients
(I've checked the source code of Gajim and Conversations), and it is
also not supported by Prosody. Cf. <https://github.com/xsf/xeps/pull/988>.
In 0.9.x we fixed an issue, because OMEMO devices should be defined in "item"
with id "current". This should work, but it won't work if there is no "current".
If there is no "current" we will just use the first item.
Issue #1384
NOTE: as per XEP-0060 §12.20, it is RECOMMENDED for the publisher to specify an
ItemID of "current" to ensure that the publication of a new item will overwrite
the existing item.
https://xmpp.org/extensions/xep-0384.html#devices
Issue: 1329
prekey is defined as `<xs:attribute name="prekey" type="xs:boolean"/>`
which allows both `true` and `1` as truthy values.
Not checking for `1` breaks omemo encryption when interacting with
clients which set prekey="1", example: psi+ 1.4.983
Regards https://github.com/profanity-im/profanity/issues/1247
Some clients (eg. PSI) are sending the stanzas delimited by whitespace
text nodes, which will fail while looping through the <prekeys/>
children and also print weird errors when iterating through the <list/>
of devices.
When debugging this, I was looking at the XML of Gajim and PSI and first
was somehow confused why Profanity printed "OMEMO: received device
without ID" while the XML looked identical (minus the actual IDs and the
JIDs of course).
However, Gajim was sending the XML without whitespace nodes in between
and PSI did not, so for example the following (with the relevant
whitespace nodes marked with X):
<message type="headline" to="..." from="...">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items type="headline" node="eu.siacs.conversations.axolotl.devicelist">
<item id="...">
<list xmlns="eu.siacs.conversations.axolotl">
X <device id="..."/>
X <device id="..."/> X
</list>
</item>
</items>
</event>
<delay xmlns="urn:xmpp:delay" stamp="..." from="..."/>
</message>
... would result in three times the "OMEMO: received device without ID"
error, because we actually have three XML text nodes here that obviously
don't have an "id" attribute.
Now since the <list/> children above aren't really a problem and only
annoying, text nodes in the <prekeys/> stanza actually cause
omemo_start_device_session_handle_bundle to return failure.
I've fixed this by explicitly matching the stanza names we are
interested in, skipping everything else.
Signed-off-by: aszlig <aszlig@nix.build>
Reported-by: @devhell
omemo_key_free() was called to free the key.
It free the key->data too. But in same cases this was not set yet. So
we need to set the data to NULL (or use calloc) at initialization so
that omemo_key_free() only frees it if it was actually allocated.
Regards https://github.com/profanity-im/profanity/issues/1148
Fix:
```
==20561== 32 bytes in 1 blocks are definitely lost in loss record 1,467
of 3,678
==20561== at 0x483677F: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20561== by 0x4B16C9: omemo_start_device_session_handle_bundle
(omemo.c:167)
==20561== by 0x43405E: _iq_handler (iq.c:214)
==20561== by 0x5AF118E: ??? (in /usr/lib64/libmesode.so.0.0.0)
==20561== by 0x5AEDBDA: ??? (in /usr/lib64/libmesode.so.0.0.0)
==20561== by 0x5AFA43E: ??? (in /usr/lib64/libmesode.so.0.0.0)
==20561== by 0x6818AA4: ??? (in /usr/lib64/libexpat.so.1.6.8)
==20561== by 0x681A3AB: ??? (in /usr/lib64/libexpat.so.1.6.8)
==20561== by 0x681D7EB: XML_ParseBuffer (in
/usr/lib64/libexpat.so.1.6.8)
==20561== by 0x5AF0A63: xmpp_run_once (in
/usr/lib64/libmesode.so.0.0.0)
==20561== by 0x432E5D: connection_check_events (connection.c:104)
==20561== by 0x4323B3: session_process_events (session.c:255)
==20561== by 0x42C097: prof_run (profanity.c:128)
==20561== by 0x4B260D: main (main.c:172)
```
In some conditions we just returned without freeing allocated variables.
Should fix following valgrind reported leak:
```
==17941== 19 bytes in 1 blocks are definitely lost in loss record 613 of
3,674
==17941== at 0x483677F: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==17941== by 0x5BB0DAA: strdup (strdup.c:42)
==17941== by 0x4B1592: omemo_start_device_session_handle_bundle
(omemo.c:126)
==17941== by 0x43405E: _iq_handler (iq.c:214)
==17941== by 0x5AF118E: ??? (in /usr/lib64/libmesode.so.0.0.0)
==17941== by 0x5AEDBDA: ??? (in /usr/lib64/libmesode.so.0.0.0)
==17941== by 0x5AFA43E: ??? (in /usr/lib64/libmesode.so.0.0.0)
==17941== by 0x6818AA4: ??? (in /usr/lib64/libexpat.so.1.6.8)
==17941== by 0x681A3AB: ??? (in /usr/lib64/libexpat.so.1.6.8)
==17941== by 0x681D7EB: XML_ParseBuffer (in
/usr/lib64/libexpat.so.1.6.8)
==17941== by 0x5AF0A63: xmpp_run_once (in
/usr/lib64/libmesode.so.0.0.0)
==17941== by 0x432E5D: connection_check_events (connection.c:104)
==17941== by 0x4323B3: session_process_events (session.c:255)
==17941== by 0x42C097: prof_run (profanity.c:128)
==17941== by 0x4B2610: main (main.c:172)
```
