AsamK
Trust but notify
When a contact reinstalls signal it's important for security reasons to be notified of the fact, because the encryption keys / safety number have changed. In the meantime, it's convenient to trust the new keys, so that the messages can continue to be sent and received. That is the behavior of the official signal clients.
From #360, there is the --trust-new-identities=always option (thanks!), but it only logs the new identity events on the debug level. Could it be made to indicate this more prominently (without having to run in --verbose mode)?
This could be a different option value: --trust-new-identities=notify. Also would work: allowing to run the trust subcommand through dBus, without having to stop the daemon.
Thanks!
I have some rough ideas for adding notifications in general. Trust notifications could also have a reason field why the identity's trust has changed. Adding a simple trust method to the dbus interface wouldn't be hard, but I'm also thinking about adding a more flexible dbus API for recipient/contact related methods.
I have some rough ideas for adding notifications in general.
I actually don't have a clear view of where a notification such as this would fit in signal-cli's output scheme (so didn't make any concrete suggestions :). As I understand it, stdout (and dbus, and socket outputs) are used for messages received from the server, and stderr is presumably for errors. Safety-number-change event does not cleanly fit into either: IIUC, the server does not send a special message announcing the change, the new messages from recipient just come with new keys; and this is certainly not an error.
Trust notifications could also have a reason field why the identity's trust has changed.
Do you mean like if a safety number has been set to "trusted" from another device (master or linked)? Because I don't think information such as "safety number has changed, because the contact has reinstalled the signal app on a new phone" is available even to the signal servers. Right?
Adding a simple trust method to the dbus interface wouldn't be hard, but I'm also thinking about adding a more flexible dbus API for recipient/contact related methods.
👍 UPD: Does not have to be dbus specifically, just as long as the daemon does not have to be stopped. Related to this: a general (i.e. not practical :) suggestion for unifying the various APIs: #830.