| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
Cleanup/newlibs
|
| |
| |
| |
| |
| | |
This part of the code was waiting for xmpp_stanza_new_from_string() from
libstrophe 0.10.0.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This partly reverts d3a387a0ec6e5265f625de87318be2de610efb01.
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.
|
| |
| |
| |
| |
| |
| |
| |
| | |
xmpp_stanza_get_child_by_name_and_ns
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.
|
| | |
|
|/
|
|
| |
Close https://github.com/profanity-im/profanity/issues/1427
|
|
|
|
|
|
|
|
| |
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 '=='.
|
|
|
|
|
| |
jid_create() for attribute "to" was called twice and the 1st object was
lost.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add stable stanza IDs to ProfMessage struct.
We parse this for 1:1 messages (MUC needs to be done too).
<stanza-id> for live messages
<result id="x"> for MAM messages
Regards MAM: https://github.com/profanity-im/profanity/issues/660
Regards Stable IDs: https://github.com/profanity-im/profanity/issues/1207
|
|
|
|
|
|
| |
We should actually process the receipts also in LMC I think.
Regards https://github.com/profanity-im/profanity/issues/805
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Add new `parse_args_as_one()` function to just use everything after the
command as the argument.
Fix https://github.com/profanity-im/profanity/issues/1404
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
8f37afcd37ad8663ca36c13ca7fbc4a431119f73
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
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Format it more readable and disable clang for this part.
Was messed up in 9b55f2dec0ea27a9ce4856e303425e12f866cea2.
|
|
|
|
|
|
| |
boothj5 gave his okay too.
Fix https://github.com/profanity-im/profanity/issues/1370
|
|\
| |
| | |
Free errors after they have been printed
|
| | |
|
| |
| |
| |
| | |
Belongs to 95ab7ee062b9fbeea73b90f69c6fef3325f880c9
|
|/
|
|
|
|
| |
`/console muc mention` additionally to `first|none|all`.
Fix https://github.com/profanity-im/profanity/issues/1371
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Fix:
```
/usr/bin/ld: src/xmpp/ox.o: in function `ox_announce_public_key':
src/xmpp/ox.c:90: undefined reference to `p_ox_gpg_readkey'
```
|
|
|
|
|
|
| |
This reverts commit 9b55f2dec0ea27a9ce4856e303425e12f866cea2.
Sorting the includes creates some problems.
|
|
|
|
| |
Regards https://github.com/profanity-im/profanity/issues/1396
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
All errors were discarded to /dev/null if the error_ptr was set to
NULL.
|
|\ |
|
| |\
| | |
| | | |
Rework logging
|
| | |
| | |
| | |
| | |
| | |
| | | |
Changed default logging from INFO to WARN.
Issue: #1353
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \ |
|
| |\ \
| | | |
| | | | |
Request Device and Key, when OMEMO is in use
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|