Skip to content

Resolve "handle changed safety numbers"

aguestuser requested to merge 100-handle-changed-safety-numbers into master

Closes #100 (closed), Closes #70 (closed), Closes #86 (closed), Closes #87 (closed)

Value

  • When a user re-installs signal on a new phone, they should be able to continue using signalboost.
    • (Currently they cannot because their safety number changes, signal does not trust it by default, and signald will therefore not read or send messages to them)
  • When an admin changes their safety number, we would like them to be blocked from sending by default so that other admins may ensure that they are not being subjected to an impersonation attack before restoring priveleges

Context

  • The only possible way to observe that a user's safety number has changed is to try sending them a message and then observe that it has failed, in which case signald emits an error message with a known form.
    • (Even if you poll for new safety numbers after you know a user has reinstalled signal, you will not see the new safety number until after signald has attempted to send that user a message and fails.)

Behavior

Self-healing scenario:

GIVEN a subscriber alice on a channel 'foo' who has just reinstalled Signal (thus triggering a safety number change)

  • WHEN any admin sends a broadcast message to 'foo'
  • THEN signalboost will notice that signald was unable to send the message to alice
  • AND THEN signalboost will direct signald to trust alice's new safety number on 'foo'
  • AND THEN signalboost will resend the message that originally failed to send to alice on channel 'foo'
  • AND THEN all subsequent messages on 'foo' will be delivered to alice as if nothing happened

Admin re-adding other admin scenario (after failed message send):

GIVEN an admin bob with phone number +1-555-555-5555 on channel 'foo' who has just reinstalled Signal

  • WHEN any other admin sends a broadcast message to 'foo'
    • THEN signalboost will notice that signald was unable to send the message to bob
    • AND THEN signalboost will remove bob as an admin on 'foo'
    • AND THEN signalboost will send an alert to all other admins that bob has been removed and must be re-added
  • WHEN another admin sends the command ADD +1-555-555-5555 to 'foo'
    • THEN signalboost will restore bob's admin priveleges on 'foo'
    • AND THEN signalboost will direct signald to trust bob's new safety number on 'foo'
    • AND THEN signalboost will send a notification to all admins that bob has been made an admin (and by whom)
    • AND THEN bob will now be able to send and receive messages as if nothing had happened

Admin re-adding other admin scenario (before failed message send):

GIVEN an admin bob on channel 'foo' who has just reinstalled Signal

  • AND GIVEN that no other admin has yet sent a broadcast message on 'foo'
  • WHEN another admin sends the command ADD +1-555-555-5555 to 'foo'
    • THEN signalboost will restore bob's admin priveleges on 'foo'
    • AND THEN signalboost will direct signald to trust bob's new safety number on 'foo'[1]
    • AND THEN signalboost will send a notification to all admins that bob has been made an admin (and by whom)
    • AND THEN bob will now be able to send and receive messages as if nothing had happened

Maintainer re-adding admin scenario:

GIVEN an admin bob on channel 'foo' who has just reinstalled Signal

  • WHEN a maintainers sends the command boost add -c <foo phone number> -a <bob phone number>
  • THEN admin will be re-added and welcomed and other admins alerted as above

Implementation Details

add registrar.safetyNumber service with #trust and #deauthorize

  • #trustAndResend:
    • consumes a message that a caller knows to have failed sending (b/c of changed safety number)
    • calls signal#trust (and observes same error-handling/notifying rules)
    • resends the originally failed message if there were no errors
  • #deauthorize:
    • strips a user of their admin privileges on a channel
    • alerts the other admins that this has happened

for self-healing scenario:

  • filter singald input for error messages flagging failed send attempts (due to changed safety numbers)
  • on failed send, forward messages to dispatcher.trustAndResend for safety number updating and message resending

for deauthorization:

  • filter singald input for error messages as for subscribers
  • on failed send, notice that recipient was an admin, triggering removal

for admin re-adding scenarios:

  • safety number retrusting for admins is achieved by sending the normal post-ADD welcome message
  • sending fails which causes signald to notice the changed safety number (if it hasn't already)
  • notice that failed message was a welcome message addressed to a new admin -- signaling that another admin intended to retrust the failed message recipient -- and trigger the same trust-and-resend-message routine used for subscribers in the "self-healing scenario"
Edited by aguestuser

Merge request reports