Cannot re-establish trust after Signal App reinstall (java.lang.AssertionError)

[bublath]

I managed to kill my Signal App on the phone (I believe I deleted a contact used by Signal and then the app won't start anymore - constantly crashing).
So I reinstalled but now signal-cli complains about the trust.
I face several issues here:
1.) Using Dbus the error message can only be found in the syslog. Via Dbus I get something cryptic:
org.asamk.Signal.Error.Failure: org.whispersystems.signalservice.api.push.exceptions.NotFoundException: Not found
2.) The message in syslog tells me to either use "trust -v "FINGER_PRINT" 73cf7df7-0792-4...... (is that the user key?)
while the help on CLI tell me to do "-v VERIFIED_SAFETY_NUMBER number"
Using the finger print or the safety number with the user key or the phone number all don't work and lead to this exception:

Exception in thread "main" java.lang.AssertionError: Unknown version: 0
        at org.whispersystems.signalservice.internal.push.PushTransportDetails.getPaddedMessageBody(PushTransportDetails.java:45)
        at org.whispersystems.signalservice.api.crypto.SignalServiceCipher.encrypt(SignalServiceCipher.java:86)
        at org.whispersystems.signalservice.api.SignalServiceMessageSender.getEncryptedMessage(SignalServiceMessageSender.java:1729)
        at org.whispersystems.signalservice.api.SignalServiceMessageSender.getEncryptedMessages(SignalServiceMessageSender.java:1689)
        at org.whispersystems.signalservice.api.SignalServiceMessageSender.sendMessage(SignalServiceMessageSender.java:1534)
        at org.whispersystems.signalservice.api.SignalServiceMessageSender.sendMessage(SignalServiceMessageSender.java:618)
        at org.whispersystems.signalservice.api.SignalServiceMessageSender.sendMessage(SignalServiceMessageSender.java:407)
        at org.asamk.signal.manager.Manager.sendSyncMessage(Manager.java:1242)
        at org.asamk.signal.manager.Manager.sendVerifiedMessage(Manager.java:2368)
        at org.asamk.signal.manager.Manager.trustIdentityVerified(Manager.java:2429)
        at org.asamk.signal.commands.TrustCommand.handleCommand(TrustCommand.java:52)
        at org.asamk.signal.App.handleLocalCommand(App.java:211)
        at org.asamk.signal.App.init(App.java:169)
        at org.asamk.signal.Main.main(Main.java:43)

3. As an alternative the error message in syslog tells me to use "trust -a while again the --help mentions "number".
   Using this both ways is not causing any error, but I still get the missing trust error afterwards.

While I discovered this with Dbus orignally all issues happen on CLI as well. So I'm actually stuck and can't get my mobile trusted by the existing signal-cli registered number. I guess I can only delete the registration now and start over.

Issue found with signal-cli 0.8.0 release as well as the latest pull

[bublath]

Did some more digging:

• The issue with "-a" is that trustIdentityAllKeys() looks for untrusted keys (but the old key is still in there and is potentially trusted, so none found), so nothing is done.
• I tried using the new safetynumber and here the issue is that the identity story is searched against existing identity numbers - and since it changed will not find anything, while using the old one apparently causes above exception (maybe due to the fact, that the safetynumber is wrong now)
• A potential solution might be change trustIdentityVerifiedSafetyNumber(). It should search by the number. Then it will either
  (a) if the safetynumber is equal and trust is unverified set the trust as now
  (b) if the safetynumber is different, update it and set it trusted. This probably should be secured by a "force" option, so you don't overwrite a safetynumber just because you had a typo. (How can I overwrite a safetynumber? I would need a reverse to computeSafetyNumber() to create an identitykey out of a safetynumber)

I tried to fix this by removing the faulty entry manually from the file. It works so far as signal-cli now received the correct safetynumber and puts it into the store.
Unfortunately I still get the same exception as above when trying to verify trust and even get exceptions for every received message from that number:
java.lang.AssertionError: Unknown version: 0
at org.whispersystems.signalservice.internal.push.PushTransportDetails.getPaddedMessageBody(PushTransportDetails.java:45)
at org.whispersystems.signalservice.api.crypto.SignalServiceCipher.encrypt(SignalServiceCipher.java:86)
at org.whispersystems.signalservice.api.SignalServiceMessageSender.getEncryptedMessage(SignalServiceMessageSender.java:1729)
at org.whispersystems.signalservice.api.SignalServiceMessageSender.getEncryptedMessages(SignalServiceMessageSender.java:1689)
at org.whispersystems.signalservice.api.SignalServiceMessageSender.sendMessage(SignalServiceMessageSender.java:1534)
at org.whispersystems.signalservice.api.SignalServiceMessageSender.sendReceipt(SignalServiceMessageSender.java:239)
at org.asamk.signal.manager.Manager.sendReceipt(Manager.java:982)
at org.asamk.signal.manager.SendReceiptAction.execute(HandleAction.java:25)
at org.asamk.signal.manager.Manager.receiveMessages(Manager.java:1731)
at org.asamk.signal.commands.ReceiveCommand.handleCommand(ReceiveCommand.java:168)
at org.asamk.signal.App.handleLocalCommand(App.java:211)
at org.asamk.signal.App.init(App.java:169)
at org.asamk.signal.Main.main(Main.java:43)

[bublath]

And maybe another clarification: I could successfully re-establish the trust with another App user and also a newly created signal-cli instance (using a different number) can communicate ok with the re-installed user. It's only the signal-cli instance that already communicated before re-installation that now has an issue.

[AsamK]

hm, might be an issue with the old session, which should be archived.
You could try to reset the session with send -e.
If that doesn't work, you can remove all sessions with that number from the sessionStore, so signal-cli will create a completely new session.

[bublath]

Ok. I restored the untouched config (which I saved before editing) and tried send -e
First attempt created an exception again (see below) and "listidentities" is still showing the old safetykey (even after "receive")
Then I used trust -v with the new safetykey (typed in as shown in the mobile device) which did not work. (understandable since its missing in the identities)
Only after did another "send" attempt the new safety key starts appearing in the listidentities additionally (meaning there are two entries for the same phone numbers), though I still cannot send anything due to "untrusted"
After repeating trust -v , I could send ok (I tried trust -a as well which also works fine).

I guess we still need an option that sort of embeds the steps above : reset the session, make a "send" attempt to get the new safetykey and even delete the old safety key/number (not sure what damage two entries might do). Maybe a "deleteIdentity" command. That still leaves it with the user if they want to try a "-v" later, but at least the registry would be clean again.

I'm keeping the old config, so I could try out any other scenarios if necessary (actually the above analysis is the result of several attempts)

Exception from the first send -e:
Failed to send/receive message (Assertion): Unknown version: 0
java.lang.AssertionError: Unknown version: 0
at org.whispersystems.signalservice.internal.push.PushTransportDetails.getPaddedMessageBody(PushTransportDetails.java:45)
at org.whispersystems.signalservice.api.crypto.SignalServiceCipher.encrypt(SignalServiceCipher.java:86)
at org.whispersystems.signalservice.api.SignalServiceMessageSender.getEncryptedMessage(SignalServiceMessageSender.java:1729)
at org.whispersystems.signalservice.api.SignalServiceMessageSender.getEncryptedMessages(SignalServiceMessageSender.java:1689)
at org.whispersystems.signalservice.api.SignalServiceMessageSender.sendMessage(SignalServiceMessageSender.java:1534)
at org.whispersystems.signalservice.api.SignalServiceMessageSender.sendMessage(SignalServiceMessageSender.java:316)
at org.asamk.signal.manager.Manager.sendMessage(Manager.java:1427)
at org.asamk.signal.manager.Manager.sendMessage(Manager.java:1355)
at org.asamk.signal.manager.Manager.sendEndSessionMessage(Manager.java:1040)
at org.asamk.signal.dbus.DbusSignalImpl.sendEndSessionMessage(DbusSignalImpl.java:122)
at org.asamk.signal.commands.SendCommand.handleCommand(SendCommand.java:64)
at org.asamk.signal.commands.DbusCommand.handleCommand(DbusCommand.java:14)
at org.asamk.signal.App.handleLocalCommand(App.java:211)
at org.asamk.signal.App.init(App.java:169)
at org.asamk.signal.Main.main(Main.java:43)
If you use an Oracle JRE please check if you have unlimited strength crypto enabled, see README

[AsamK]

I've pushed a commit that should fix the issue. Though I'm not exactly sure how the session gets into this broken state ...

[bublath]

Much better now. Though I think there is still room for improvement.

1. send a message
   reply: Failed to send message: Untrusted Identity for xxxxxxx
2. listIdentities
   There are two entries now for the number - the old one (still trusted) and the new one (untrusted). All ok so far.
3. trust -v (and I on purpose chose "accidentally" the original entry) , reply:
   Reply: WARN Manager - Failed to send verification sync message: Untrusted identity key!
   So far so good, but after listidentities everything still looks the same.
4. trust -v with the correct key
   No reply, but after this the entry turned trusted and send works ok

We now still have two trusted entries for the same number.
I believe we should remove the old entry or at least set it to UNTRUSTED on the reply we're getting on (3)
latest on (4) when the new number gets verified, we could delete the double entry. Its ensured now that it is obsolete and wrong.