Handle KeyTransport message correctly#33
Open
root-hardenedvault wants to merge 2 commits intogkdr:devfrom
Open
Handle KeyTransport message correctly#33root-hardenedvault wants to merge 2 commits intogkdr:devfrom
root-hardenedvault wants to merge 2 commits intogkdr:devfrom
Conversation
omemo_message_export_encrypted() should not return early if only its payload is absent. omemo_message_prepare_encryption() should be able to accept an outgoing_message without body, which would become a template of a KeyTransport message. Signed-off-by: HardenedVault <root@hardenedvault.net>
root-hardenedvault
force-pushed
the
omsg
branch
from
cc1c69d to
5136540
Compare
root-hardenedvault
changed the title
root-hardenedvault
added a commit
to hardenedvault/lurch
that referenced
this pull request
Feb 11, 2021
Simply calling omemo_message_create() cannot compose a valid KeyTransport message, which should at least have an ordinary "message" node, so we should first make up such message without a "body", then let omemo_message_prepare_encryption() of libomemo hamdle such case: gkdr/libomemo#33 Signed-off-by: HardenedVault <root@hardenedvault.net>
root-hardenedvault
added a commit
to hardenedvault/lurch
that referenced
this pull request
Feb 11, 2021
Simply calling omemo_message_create() cannot compose a valid KeyTransport message, which should at least have an ordinary "message" node, so we should first make up such message without a "body", then let omemo_message_prepare_encryption() of libomemo hamdle such case: gkdr/libomemo#33 Signed-off-by: HardenedVault <root@hardenedvault.net>
According to: https://xmpp.org/extensions/xep-0384.html#message-structure-description Nodes for encrypted symmetric <key/> for a particular recipient should be nested in a <keys/> node with its "jid" attribute set to the recipient's bare JID, with an optional "kex" attribute for key exchange usage. Functions related to these above are modified accordingly. Signed-off-by: HardenedVault <root@hardenedvault.net>
root-hardenedvault
force-pushed
the
omsg
branch
from
630151e to
90ca270
Compare
Owner
|
hi @root-hardenedvault, thank you for your contribution!
|
Author
|
But how to compose a valid KeyTransport message from omemo_message_create()? as stated in: |
Contributor
|
@gkdr: Any news on it? |
1 similar comment
Contributor
|
@gkdr: Any news on it? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Handle KeyTransport message correctly
omemo_message_export_encrypted() should not return early if only its
payload is absent.
omemo_message_prepare_encryption() should be able to accept an
outgoing_message without body, which would become a template of a
KeyTransport message.