Messages getting lost because "derived ephemeral key did not match key provided in message"

[hoehermann]

This also happens in signald. :(

org.signal.libsignal.metadata.InvalidMetadataMessageException: org.signal.libsignal.protocol.InvalidMessageException: invalid sealed sender message: derived ephemeral key did not match key provided in message

[mike-gh]

Hi Hermann,

I've seen this issue myself. I see that it's waiting an upstream fix. I wonder perhaps, if it might be worth considering how purple-signald handles these errors? At the moment, it's disconnecting and remaining disconnected until I click retry. That's annoying. Even more so if I receive several of these messages, since it disconnects each time, so if I receive 12 such messages, I have to click "reconnect" 12 times before it will connect. I'm not sure exactly what this error means and how much of information is retrievable? Is the message content actually available and can we display it with an error warning? If not, can we get the intended recipient and display a message in the respective chat window to the effect "a message was received from this user but unreadable"? If we can't discern any usable information from the message, can we instead print an error to the Pidgin logging system? Disconnecting seems perhaps to be an excessive response, unless there's a good reason that I'm missing?

Thanks for your ongoing work on purple-signald.

Kind regards,
Mike.

[hoehermann]

I, too, find terminating the connection a bit excessive. Since the message is lost and never to be seen again on that very client, I am somewhat torn between "the user should definitely know" and "nothing we can do about it now". Maybe using a conversation window like in https://github.com/hoehermann/purple-signald/tree/dev is a reasonable compromise? What do you think?

[demure]

Another project I use (rdircd for discord) makes a few option debug channels (irc bias), which work well. Having a debug 'chat' seems like it would be a decent aproach.

[mike-gh]

While we can't do anything about the fact that the message went missing, I do think it's something that the user should know about. On reflection, if the user / group that the message was intended for cannot be determined, I don't think it's a good idea for the error to be sent to the Pidgin system log, since I'm not in the habit of viewing it periodically to see if anything is there, I will only look if I'm diagnosing a specific problem. I think therefore that the suggestion of having a purple-signald-system-messages or similarly named chat window to display the information would be the best approach.

[hoehermann]

In f58cdfe, I am writing to the users's own conversation. That is actually where the official client puts error messages, too. Should I push that on the master branch?

[mike-gh]

It looks good to me. I think it would be good to push it to master.

[hoehermann]

I think it would be good to push it to master.

Done.

[hoehermann]

Due to the persisting issues within signald, I have been spending time on a different back-end in https://github.com/hoehermann/purple-presage. At the moment, it does not support more than simple messaging, but that it does more reliably than signald. That is until I break it. Which happens every other commit. I have never used rust before.