| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Fixes the bug mentioned in
https://github.com/profanity-im/profanity/issues/1478#issuecomment-794161606
The rest of https://github.com/profanity-im/profanity/issues/1478 I
can't reproduce. Seems to work fine.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In profanity are two handlers for device list:
* _handle_own_device_list
* _handle_device_list_start_session
I seems both handler will start a session via
omemo_start_device_session_handle_bundle
_handle_own_device_list will also make sure, that the own device is withing the
omemo device list. If we add the _handle_device_list_start_session into the
hashmap, we are not going the republish ourself, in case we clean-up the device
list from another client.
This will maybe fix #1552
99 Little Bugs in my Code.
Take one down.
Patch it around.
113 Bugs in my Code
|
|\
| |
| | |
OMEMO: Don't encrypt to yourself (MUC)
|
| |
| |
| |
| | |
Use connection_get_barejid instead of connection_get_fulljid.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As defined in XEP-0384 the application should not encrypt the message to own
devices. Within a groupchat, yourself are a recipients as well.
We will check the recipients and filter out the own device of the own jid.
This Pull Request will fix Issue: #1541
|
|/
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Add OMEMO trust mode capabilities.
* ToFu / first usage
* blind trust
* manual
|
|
|
|
|
|
|
|
|
| |
If the message (key) can't be encrypted for any device, sending the
message is refused and an informative error message is presented to the
user.
Also, don't encrypt for the same device, since the OMEMO XEP disallows
this.
|
|
|
|
|
|
|
|
|
| |
So that off_t is defined in all files (so far http_upload.c and
http_download.c too) the same way.
Fix https://github.com/profanity-im/profanity/issues/1512
Thanks @pasis for finding the solution!
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
We require c99/gnu99 anyways.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This reverts commit 9b55f2dec0ea27a9ce4856e303425e12f866cea2.
Sorting the includes creates some problems.
|
|
|
|
| |
Regards https://github.com/profanity-im/profanity/issues/1396
|
|\ |
|
| |\
| | |
| | | |
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
|
|/ /
| |
| |
| |
| | |
It just does a free.
Related to b580b9ef119045f142fa4baa9689a1c5ce8864ef
|
|/
|
|
|
| |
We often had a use case where we want the account specific data dir.
Let's create a function for this instead of doing it by hand each time.
|
|
|
|
| |
Instead of connection_get_fulljid() and then creating a Jid from it.
|
| |
|
|
|
|
|
|
|
| |
We decrypt both 12 and 16 bytes.
And send 12 instead of 16 bytes now.
Close https://github.com/profanity-im/profanity/issues/1272
|
| |
|
|
|
|
| |
Fix #1068
|
|
|
|
|
|
|
| |
16 bytes IV should be used. Some clients can't use it so we should also
support decrypting 12 bytes IV.
Fix #1253
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
I don't see a reason for strdupping here.
|
| |
|
|
|
|
| |
I don't see a reason for strdupping here.
|