| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libmicrohttpd 0.97.1 changed some types.
These commits adapt stabber:
https://github.com/profanity-im/stabber/commit/f33c4b6ba9281d1e5ff7c488cc0df00e331c98ba
https://github.com/profanity-im/stabber/commit/81f38c6a3377e2a1df3bfbb223f98bdaf3fd8ffa
Tumbleweed does not yet have the latest libmicrohttpd in its
repositories. But it is updated in the devel repo.
So should land there in the next couple of days.
Let's disable building stabber on TW for that time.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
Tip about pre-push hook in contribution guidelines
|
| | |
|
|/ |
|
|
|
|
| |
Regards https://github.com/profanity-im/profanity/issues/1396
|
|
|
|
| |
Regards https://github.com/profanity-im/profanity/issues/1396
|
|
|
|
|
| |
People should run `make format` before doing a commit.
Fix 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
|
|\
| |
| | |
Log errors from eval_password
|
|/
|
|
|
| |
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
|
|\ \ \ \
| |/ / /
|/| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
|\ \ \ \
| | | | |
| | | | | |
Cleanup carbons/chat handling in message.c
|
| | | | |
| | | | |
| | | | |
| | | | | |
This one will always be set.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
So that we don't have to pass the wrapping stanza and can handle
the error nicer.
|
|/ / / /
| | | |
| | | |
| | | |
| | | | |
Trying to simplify the conditions so we don't have duplicate code
in both of those functions.
|
| | | |
| | | |
| | | |
| | | | |
Since its done in both cases.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Authored by DebXWoody in:
https://github.com/profanity-im/profanity/pull/1369
Regards: https://github.com/profanity-im/profanity/issues/1366
Since I'm in the process of cleaning up message.c I take this now
so he doesn't have to rebase.
I also omitted the _handle_normal() case since I'm not sure that would
be correct.
Probably will be addressed again when continuing the cleanup.
|
|\ \ \ \
| | | | |
| | | | | |
Add missing -o flag for omut example
|
|/ / / / |
|
|\ \ \ \
| |_|_|/
|/| | | |
Fix messages with receipt request not displayed
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Messages from Conversations contains:
<request xmlns='urn:xmpp:receipts'/>
And would not be displayed in Profanity as it never reached
_handle_chat(..).
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
So far we logged when we receive a message without a type. Which is
actually quite common and makes no sense.
|
| | |
| | |
| | |
| | |
| | | |
RFC 6121 allows only few types.
So we can also remove that check in _handle_chat().
|
| | |
| | |
| | |
| | | |
Both cases are tested before entering that function.
|
| | |
| | |
| | |
| | |
| | | |
AFAIK it can only be one.
Except at STANZA_NS_MUC_USER which is used in several cases.
|
| | | |
|
| | | |
|