trust changed safety numbers

Context

• when a user reinstalls signal, their safety number will be changed, signald will not trust them, and thus will not send messages to them
• fix: trust any new safety numbers automatically via signald unix socket message

Rough Guide at Implementation from a hotfix on 2019-08-13

• failure to send due to a new safety number manifests as a org.whispersystems.signalservice.api.push.exceptions.EncapsulatedExceptions: null error in the logs
  • can we listen for the message in which the safety number actually changes instead?
• open a socket for testing with:

nc -U /var/run/signald/signald.sock

• send a message of this form to retrieve the safety number:

{
  "type": "get_identities",
  "username": "<channel_phone_number>", 
  "recipientNumber": "<user_phone_number>" 
}

• this should return a message that looks like this:

{
  "type":"identities",
  "data":{
    "identities":[
      {"trust_level":"TRUSTED_VERIFIED","added":1560446989919,"fingerprint":"<really long fingerprint>","safety_number":"<really_long_safety_number>","username":"<user_phone_number>"},
      {"trust_level":"UNTRUSTED","added":1563916298217,"fingerprint":"<different really long fingerprint>","safety_number":"<different_really_long_safety_number>","username":"<user_phone_number>"}
    ]
  }
}

• grab the fingerprint field from the most recentidentity record marked as UNTRUSTED, and use it to send a trust message that looks like this:

{
  "type": "trust", 
  "username": "<channel_phone_number>", 
  "recipientNumber": "<user_phone_number>", 
  "fingerprint": "<really_long_fingerprint>" 
}

• you will get an error message back, but you can confirm that it actually worked by sending a get_identities message again, and confirming that all identities are trusted (or at least the one you just trusted is trusted. :))