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
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
Old: `/intype on|of`
Typing information is printed in console and titlebar.
New: `/intype titlebar|console on|off`
Typing information can be configured in more detail.
Regards https://github.com/profanity-im/profanity/issues/1516
Our variable `alphabet` contains 62 alphanumeric symbols + '\0'.
When we use sizeof(alphabet) we will get 63 due to that.
But we want to choose a random numbers from the 62 alphanumeric letters only.
This mistake caused us to have strings with a max length of `length`
instead of the exact length.
When doing https://github.com/profanity-im/profanity/issues/1520
this caused our algo for muc reflection to not catch since we expect the
random ID to be exactly 15 symbols long in `message_is_sent_by_us()`.
* Generating a unique file name in tmp_dir folder
* Changed exec of vim to exec of sensible-editor
* Test file exists and create file with "private" rights
* Send a preview of the message in the window
* Delete temp file
It was a great ride!
IDs look instead of
`TE5BTDc2ZTc3YTMwZGU3MDgzMzllOTliNGExNjVmMjZkMTY1ZmUyZGEyNTUxMjVmODBkMmQzOGMxYWI2ZjAxNzdiM2Q=`
more like `7HcnNSoO1MVvb0p9a9e293152922853e910b8b1a65bb26e225a0568` now.
Regards https://github.com/profanity-im/profanity/issues/1520
We still has our identifier into it to filter MUC reflected messages.
profident maybe should be changed to be longer or be generated upon each
start.
Currently, only `chat_log_omemo_msg_out` can fail (i.e. return `NULL`
instead of a stanza id). In this case, the message is neither printed to
the chat window nor added to the log (since it wasn't sent).
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.
The function `omemo_start_session` was effectively called twice in the
`/msg` command: Once in `chatwin_new` and afterwards in `cmd_msg`. I've
removed the second call.
