Through asprintf() we can get rid of malloc() + sprintf().
Also we don't need to calculate the strlen() again since asprintf()
returns the bytes printes.
Only non UTF-8 characters. But that was true before already.
Main changes:
1. Attributes instead of tags
2. Read the optional <header> tags and send them in the HTTP PUT header:
* Authorization
* Cookie
* Expires
Co-authored-by: Martin Dosch <martin@mdosch.de>
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>.
Regards https://github.com/profanity-im/profanity/issues/1488
Actually I would have loved to see the stanza that caused the segfault
since I'm not entirely sure whether this actually means that we do
something wrong earlier on.
Right now I don't know why the to_jid should be empty.
Let's prevent the segfault for now and see whether we get further
bugreports later.
Segfaulting issue got introduced with dd566d8d56.
On every write to `chatlog.db` syslog throws
```
profanity: vfprintf %s NULL in "INSERT INTO `ChatLogs` (`from_jid`,
`from_resource`, `to_jid`, `to_resource`, `message`, `timestamp`,
`stanza_id`, `archive_id`, `replace_id`, `type`, `encryption`) SELECT
'%s', '%s', '%s', '%s', '%s', '%s', '%s', '%s', '%s', '%s', '%s' WHERE
NOT EXISTS (SELECT 1 FROM `ChatLogs` WHERE `archive_id` = '%s')"
```
in `/var/log/messages`. Checking for `NULL` except in the fields the DB
is expected to throw errors for, satisfies OpenBSDs security measures
Error log:
GLib-CRITICAL - g_string_insert_len: assertion 'len == 0 || val != NULL' failed
Check if a room name exists, before adding the name into the title bar.
Some functions changed in the meantime.
stanza_get_child_by_name_and_ns() got dropped and
xmpp_stanza_get_child_by_name_and_ns() from newer libstrophe is used.
It was added in f7fe87dd4e when I rewrote
window functions to include more infos (not just char* but whole jid
struct I think).
The same todo was added to win_print_outgoing_muc() but removed in
f3d9de133e.
This TODO should have been removed in
f3d9de133e since there we added the myjid
parameter.
Discovered by @aba-hollerer.
Mistake was introduced in b6b7dd5ad4
probably due to a wrong copy/paste.
First wasn't reproducible because I had `/receipts request on` and thus
win_print_outgoing_receipts() is used which has the correct
THEME_TEXT_ME.
Fixes https://github.com/profanity-im/profanity/issues/1441
`profanity -f my` created ~/.local/share/profanity/logs/my.log`.
It would be nicer if one could define the actual path, so one can choose
another directory or even use /dev/null.
Fixes https://github.com/profanity-im/profanity/issues/1442
00dbc1ba7c attempted to fix
https://github.com/profanity-im/profanity/issues/1449.
Here we revert the part about initializing is_omemo in chatwin_new()
since this is done in win_create_chat() already.
The actual mistake was the wrong cast of the muc window which is fixed
by the same commit. The mistake was introduced in in 3370418d71.
While being at it we also remove the is_ox initialization since this is
handled in win_create_chat()/win_create_muc() too.
`profanity mangen` will create for each command (`/account`, `/roster`)
an own manpage (`profanity-account.1`, `profanity-roster.1`)
See https://github.com/profanity-im/profanity/issues/1444
Needs some polishing formatting wise.
Regards https://github.com/profanity-im/profanity/issues/1435
So far we didn't print the error if it contained `<error
type="cancel">`. It appears that the code always thought this is a
service-not-available (so one is either blocked or the account doesn't
exist) and printed `Recipient not found`.
But there can be other errors as well. Like in above mentioned issue
`not-allowed`.
Let's just print the text.
In case of the cancel type we still remove the jid from the chat
sessions. I'm not entirely sure whether this needs to be done in other
cases too.
Using g_date_time_new_now_utc instead of g_date_time_new_now_local
Using g_date_time_format(timestamp, "%FT%TZ") instead of "%FT%T%:::z"
Edit:
DebXWoody created this patch because ejabberd returned an error with the
old date format.
When a bookmark is created with '/bookmark add' command,
ext_gajim_minimize remains uninitialised in new bookmark object and
is read further in _send_bookmarks().
Initialise the field with 0.
Fixes#1432.
Commit f12161f fixes memory leak, but introduces use-after-free issue.
Allocate new memory for win_name with g_strdup() since it is freed with
g_free() later.
This partly reverts d3a387a0ec.
For proanity 0.9.x we still wanted to support older glib versions so
that we can be packaged for various linux distros.
Now with 0.10 we want to move on.
Replace our own stanza_get_child_by_name_and_ns() with the upstreamed
xmpp_stanza_get_child_by_name_and_ns() provided by the new
libstrophe/libmesode 0.10.0.
This allows profanity to work without segfaulting from NULL
pointer dereferences when used with NetBSD libcurses.
Basic functionality was tested, there may be more NULL pointer
issues hiding.
- Add NetBSD as a recognized platform without -ldl.
- Allow building with NetBSD libcurses instead of ncurses.
- Portability to NetBSD sh - use POSIX '=' instead of '=='.
archive_is is <stanza-id> or <result id=""> and should identify one
message stable and uniquely.
See XEP-0359: Unique and Stable Stanza IDs.
We need this for example for this situation:
* we go online with Profanity
* we fetch all messages since yesterday
* we add them to the db
* we go offline
* we go online with Profanity
* we fetch all messages since yesterday
* we only want to add the new ones
So far we don't ask MAM "give me all since last 'id'" but since a
certain date.
In case no archive_id will be set, it will be `(null)` and thus should
be inserted anyways because it won't find a value with (null) in that
row.
Because when adding we use `message->stanzaid ? message->stanzaid : "",`
so it will be empty in such a case.
Regards MAM: https://github.com/profanity-im/profanity/issues/660
Regards Stable IDs: https://github.com/profanity-im/profanity/issues/1207
We use malloc() to allcoate memory for the arguments.
But later on in cmd_funcs.c we use g_strfreev() to free it.
Let's use g_malloc() to allocate instead.
Second change is to use g_malloc() and g_free() for a gchar.
Autocomplete only completed on|off.
Now:
`/lastactivity get` -> get server uptime
`/lastactivity get <jid>` -> get user lastactivity
`/lastactivity set on` -> enable for self
`/lastactivity set off` -> disable for self
Fix https://github.com/profanity-im/profanity/issues/1411
`parse_args()` and `parse_args_with_freetext()` shared a lot of common
code.
Let's have a helper function `_parse_args_helper()` for that. The
`with_freetext` parameter will make it behave like
`parse_args_with_freetext()`.
In preparation for https://github.com/profanity-im/profanity/issues/1404
This commit partly reverts
8f37afcd37
Which was using a wrong approach to achieve this.
It changed parse_args() to have a -1 for infinite parameters.
But actually parse_args_with_freetext() should have been used exactly
for this behaviour.
Discovered when checking for
https://github.com/profanity-im/profanity/issues/1404
Discovering Public Keys via PEP
* 4.3 Discovering Public Keys of a User
* 4.4 Requesting Public Keys
* Import Public Keys into GnuPG's local keyring.
Issue: #1331
If we receive a message we get:
<< room message: eagle@conference.anoxinon.me (win 2)
Same for private chats and regular chats.
And several other kinds of notifications.
If we only receive notifications from a chat window it would be nice to
also clear the hilight on the console window since we already catched up
by reading the actual message in the chat window.
Probably not the best description :-) I hope you get it..
Regards https://github.com/profanity-im/profanity/issues/1399
src/pgp/gpg.c:p_ox_gpg_readkey
Used to read a public key from a file. The function will return the fingerprint
of the file and the base64 encoded key.
src/xmpp/ox.[hc]
ox_announce_public_key(const char* const filename) can be called from the /ox
announce <filename> command. The key within the file will be pushed on PEP and
the Metadata node will be set.
Issue: #1331
Plain chat messages not working for non-carbon + no OTR support.
On master we did some clean-up. The problem is at https://github.com/profanity-im/profanity/blob/0.9.patch/src/event/server_events.c#L625 (0.9.0). The implementation looks like:
- HAVE_LIBOTR is set - _sv_ev_incoming_otr
- HAVE_LIBOTR is not set - _sv_ev_incoming_plain
I think the `_sv_ev_incoming_otr` can handle otr and plain, because I didn't find a `_sv_ev_incoming_plain` if `HAVE_LIBOTR` is set.
On master for 0.10.0 the implementation is much better:
https://github.com/profanity-im/profanity/blob/master/src/event/server_events.c#L623
But, we just call `_sv_ev_incoming_otr` independent of `HAVE_LIBOTR`.
Unfortunately, `_sv_ev_incoming_otr` is doing nothing if `HAVE_LIBOTR` is not set:
https://github.com/profanity-im/profanity/blob/master/src/event/server_events.c#L538
I did some more clean-up at sv_ev_incoming_message and changed the implementation of `_sv_ev_incoming_otr`.
```
static void
_sv_ev_incoming_otr(ProfChatWin *chatwin, gboolean new_win, ProfMessage *message)
{
// OTR or plain
plain
}
```
The caller do not take care of `HAVE_LIBOTR`, call `_sv_ev_incoming_plain` if you are sure it's a plain message or call `_sv_ev_incoming_otr`. `_sv_ev_incoming_otr` can be used for otr / plain or for plain only.
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
Messages from Conversations contains:
<request xmlns='urn:xmpp:receipts'/>
And would not be displayed in Profanity as it never reached
_handle_chat(..).
So far:
```
/executable urlsave html "test %u" results in url.save.cmd[html]=test %u
/executable urlsave * "test %u" results in nothing.
```
Probably due to limitation in .ini file format.
Additionally to ec7e635e75.
In the earlier commit I just setted the test value ignoring the real
format.
Now we correctly transform:
```
[logging]
urlopen.cmd=xdg-open
```
into:
```
[executables]
url.open.cmd=false;xdg-open %u;
```
c56d530b67 by peetah moves:
urlopen.cmd from the 'logging' to a new 'executables' section in profrc
avatar.cmd from the 'logging' to a new 'executables' section in profrc
We need to adapt this so that users don't have to set the setting again
themselves.
The display of commands associated with specific file
types and protocols will need to be implemented later,
but this requires to use private data of the GKeyFile
structure, which can be a maintainability issue on the
long term.
Signed-off-by: Pierre Mazière <pierre.maziere@gmx.com>
/urlopen is replaced by /url with the following sub commands:
/url open <url>
/url save <url> [<path>]
Signed-off-by: Pierre Mazière <pierre.maziere@gmx.com>
Where GKeyFile usually use the pref[locale] format to define
locale specific translated data, it is here hijacked to be used
as pref[option] in order to specialize a preference according
to an option:
open.url.cmd[pdf] = pdf-viewer
open.url.cmd[jpg] = image-viewer
Signed-off-by: Pierre Mazière <pierre.maziere@gmx.com>
strncpy(3) is not so safe function and can lead to mistakes. For
example, strncpy(dest, "Profanity", 10); is redundant and leads to
problems when someone changes the source string.
Different example is when 3rd argument equals to length of the
destination buffer. strncpy(3) doesn't terminate string with '\0' when
it truncates. Therefore, the destination string becomes corrupted.
Zeroize storage for 'nid', so the last byte remains '\0' in case of
truncate.
Since d92c576aa5
we rely on g_spawn_sync().
Which doesn't do variable/glob expansion.
For our use of call_external() in opening and URL or avatar this is
fine.
For getting the password we want to be able to use ~ for our files.
Let's use a shell here.
Fix https://github.com/profanity-im/profanity/issues/1364
98c38dc6d6
sets C99 as standard.
strdup() is not part of C99.
For now set `-D_POSIX_C_SOURCE=200809L` macro to have strdup() in C99.
Using `gnu99` instead would be another option.
We should take more care to use glib functions whenever possible.
Regards https://github.com/profanity-im/profanity/issues/1357
Found this when looking to fix bug https://github.com/profanity-im/profanity/issues/1357
Not sure if it is related.
man 3 getenv sais:
```
As typically implemented, getenv() returns a pointer to a string within
the environment list. The caller must take care not to modify this
string, since that would change the environment of the process.
```
Some systems don't provide recent libstrophe releases. When older
version of libstrophe is detected, don't build legacy auth support.
To simplify this patch, report about unsupported legacy auth and
keep commands option as is.
Profanity requests the device list and keys for contacts, also when the user
hasn't generated the OMEMO key. If the user has no OMEMO key, there is no need
to request OMEMO information.
Issue: #1332
Memleak was reinroduced in d92c576aa5
It was already fixed in ac5ce105ac
But the rebase peetahs rebase ontop of master took the wrong changes.
I decided to pull anyways and fix since reviewing/giving feedback
without GH probably takes longer.
Fix https://github.com/profanity-im/profanity/issues/1280
p_contact_set_presence() is triggered in
(roster_process_pending_presence) to set the presence to online
after the roster is displayed.
This happened to me _every time_ with one certain account on my server.
But not even once with other accounts on my server.
I don't understand why that is the case, but AFAIK the code should be
like it is in this PR anyways.
roster_process_pending_presence() was added there in
973a05d15a to fix
https://github.com/profanity-im/profanity/issues/1050
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
There is code to redraw the ui, because the user may enter a passphase for the
private key. There was also a ui_init, which shouldn't be called, because it
will set the status to the initial state, which is 'offline' and 'no tls'.
Issue: #1327
A autoping is to make sure that there is still a connection between server and
client. If the application receives incoming stanza, the connection is fine.
There is no need to wait for response, if there are other incomings.
Issue: #1333 and #1315
With d1d0ad8d1a we set a timestamp to now
for all messages upon receival. Even if the original message didn't
contain any timestamp. So we can use the timestamp of retrieval for
logging and displaying and don't get them at each of those location
where they might differ.
This means that timestamp will never be NULL.
I don't see why we would want to check for the chat state only if
timestamp isn't there.
Probably because in XEP-0085 there is not timestamp defined.
So if it thats stanza it's not there and we can parse quicker, but there
is nothing forbidden it to be there.
Related to https://github.com/profanity-im/profanity/issues/1339
In console autocomplete from roster.
In muc autocomplete from occupants lits.
In 1:1 regular chat autocomplete from active resources of currently
selected user (new).
Also give a hint (/help resource) how to set the resource should a user choose that way.
Fix https://github.com/profanity-im/profanity/issues/1337
1f8b1eb740 made it possible to have utf8 chars as correction chars. So since then prefs_get_correction_char() doesn't return a regular char but a char*.
Seems like there was an oversight that we need to use %s then.
For some time users could choose to have the old way "unanimous" where
all the MUC history is just grey (or whatever was set). Now it is always
just displayed like regular new incoming MUC text.
Profanity request the OMEMO Device List for all members, also if the MUC is
anonymouse. If the user is Admin / Owner, the device list will be requtest.
Issue #1315
glib functions can allocate a GError object that must be freed with
g_error_free(). Otherwise a memory leak happens.
There are similar unfixed places in omemo, check:
grep "&error" src/omemo/omemo.c
Fixes#1304.
MUCPMs and regular chat messages get printed with the same code.
But we don't save MUC PMs in the sqldb, because another jid could use
the same nick the next time.
And if we would take the log out we would need a different routine,
checking for resourcepart too.
Fix https://github.com/profanity-im/profanity/issues/1312
Only when we start the conversation.
Not yet when we get messaged and a new window is opened.
Need to have sorting of messages in the window buffer then, I guess.
Also MAM IQ should only be send one time in such a case.
If MAM is enabled history from sql backend will not be shown.
`mam` in profrc enables experimental MAM.
Can change soon again. Don't rely on stuff in this stage ;)
Later we will have several options.
Getting everything since last timestamp (if none everything at all).
Getting everything since today + configure time (1 week).
Should also have a reload all command like conversations once you
cleared the history.
All MAM messages should be written into sql db.
And then probably displayed from there so that regular history works
too.
MAM messages don't have a type nor a from.
If we detect a message without type let's log it and exit without
continuing to try to parse it.
Otherwise we go into _handle_chat() and crash on the no from.
