GitLab

update splash with downtime notice

See merge request !602

[hf] fixup mr !599 - cleanup SignalReceiver/ContactStore

See merge request !601

SignalReceiver:

- make helpers in different branches of `#dispatch` return
  `Unit` instead of `Job?` (we never used the job and it was odd to
  return null from 3/4 of the branches!)
- call `ContactStore#create` with uuid and phone number from
  `#handlePreKeyBundle` (instead of calling overloaded `#create` that
  takes an envelope as arg) to (1) be simpler, (2) make it more
  explicit why we are storing both pieces of data at this
  point in the session lifecycle
- revise the comment for `#handlePreKeyBundle` (it is a "hot spot" and
  likely to be the source of lots of confusion to future us when less
  debugging state is loaded in our heads!)

ContactStore

- revise `ContactStore#hasContact` to be slightly more
  straightforward (if less terse)
- remove overloaded `#create` (which is no longer called)

[#498] Resolve contact ids

Closes #498

See merge request !599

in SignalReceiver:

- fix bug in which we dropped sender address from inbound identity
  failure socket response after identity failure during decryption
  - we no longer have access to sender address in the envelope for
    sealed sender messages, so by default the address is not
    available (and its bad to omit it b/c client needs it to trust new key)
  - however: we can recover the address by getting an identifier from
    the error message (all `ProtocolException`s store a `sender` field that
    is the equivalent of `SignalServiceAddress#identifier`) and use it
    to query the contact store for the uuid and number needed to
    construct an address

in SignalReceiver & SignalSender:

- update unit tests that wrongly used `account.identifier` (defaults
  to uuid) instead of `account.id` (defaults to phone number) for
  contact lookups

in ProtocolStore:

- create contact in test setup to allow calls to `#resolveContactId`
  to succeed

in `SignalReceiver`:
- reorganize execution flow in `#dispatch` to be more cohesively grouped
- add `numberOfMessagesWithoutProfileKey` counter to track messages
  received from desktop app without "continue" being tapped from phone
- move `null` return up into `dispatch` (where it more obviously
  refers to whether or not a job is returned from a branch of the
  `when` statement and the helpers that don't return a job have a more
  sensible signature of `Unit`)
- in `#processPreKeyBundle`: remove unnecessary `withContext` wrapper
  and touch up comments
- in `#processReceipt` remove unnecessary check for
  `isSealedSender` (receipts are always unsealed) and touch up comments

in `ContactStore`:
- overload `#create` to take an account and envelope to make for more
  ergonomic calling from `SignalReceiver`

re: `SignalSender`
- add tests for `#sendProfileKey` and `#sendReceipt` helpers used by
  `SignalReceiver`

(necessary to make removal of non-null constraint safe)

- sadly, `isProfileKeyUpdate` does not appear to be dependably `true`
  on all first messages containing a profile key
- so... we store profile keys on every message (for now)

- (this is needed to create sessions with actual contacts for reasons
  that remain unclear!)

- in m2_WIP, we modified `SignalServiceAddress#identifier` to prefer
  phone numbers to UUIDs (as opposed to preferring UUIDs to phone
  numbers, as the upstream version does)
- we did this in an attempt to attempt to solve a bug that was
  better addressed by making the `phone_number` column on the
  `contacts` table nullable
- here we revert that change it because:
  - (1) it is risky to diverge from mainline signal on this part of
    the data model
  - (2) the change appears to have introduced another bug in which in
    which first-time incoming prekey bundle messages could not create
    a session b/c of a Bad Mac error

[498] Change storeUuid to storeUuidOrPhoneNumber, split resolve into resolve AND resolve or create id.

- testssss!
- there is currently a race in the first inbound message that we think
  can be resolved either by:
  - (1) making the process prekey helper suspend/async/await (so
    `processMessage` doesn't happen until it finishes)
  - (2) doing some refactoring of relationship btw/ ContactStore &
    AccountProtocol store so that ContactStore can know about the
    session lock (and by taking it, prevent session Store from trying to
    call `resolveContactId` before we've crated a contact)

[hf] add docs for running 2 signal installations on 1 device

See merge request !600

[splash] add waitlist notification to how-to guide

See merge request !598

[hotfix] handle signal verification codes with or without hyphens

See merge request !595

[#493] modify identity store to store one identity key per contact

Closes #493

See merge request !596

- note, in signal-android this is performed by:
  - calling `archiveAllSiblings` (to archive all sessions than the
    session with the same device id as the `SignalProtocolAddress`
    provided by the caller) in the body of `#saveIdentity`... IFF
    that call performed an update to a new key.
    - see: `TextSecureIdentityStore#saveIdentity`
  - then archiving the session for the device corresponding to the
    address provided by the caller IFF the `#saveIdentity` call
    performed an udpate
    - see:  `IdentityUtils#saveIdentity`
- we can accomplish this more cleanly/efficiently by simply archiving
  all the sessions at the same time IFF a given call to
  `#saveIdentity` performs an update. so we do that!

(to help with sleuthing!)

- having modified the shape of the identity store to disregard device
  id's, we no longer need to query for identity records by
  fingerprint. (this was a workaround to not have to lookup all
  fingerprints for a given contact id, which is now
  unnecessary. moreover, it necessitated looking up an indexed field,
  which will become impossible in the case where the identity store is
  a redis-backed key-value store)
- here, we modify (and rename) `#trustFingerprint` and add
  `#untrustFingerprint` (which will be needed in our ETL job) to
  lookup identity records by their address, and (as a layer of
  safety), throw if we are trying to trust a fingerprint that is not
  the fingerprint we currently have stored for that address's contact id.
- we then do a couple of data model tricks that will pay off in a
  protocol store refactor:
  - first, we add `VerifiedAccount#identifier` and `SignalcAccount#identifier` (and
    allow them to default to uuids, which will soon be safe once we have
    a `ProtocolStore#resolveId` function in place to disambiguiate btw/
    uuids and e164 numbers).
  - then, we leverage this to (pretty) safely convert from a `SignalcAddress`
    to a `ProtocolStoreAddress`
  - finally, we use the final converter to allow us to call the
    libsignal-defined `saveIdentity` (which requires a
    `SignalProtocolAddress`) from `SocketReceiver`, thus eliminating
    the need for `IdentityStore#saveFingerprintForAllIdentities`, which we delete
- to make our confidence in our tests slightly higher, we modify
  `StringGen#genFingerprint` to run the same code that signal and signalc run
  when generating the fingerprint we send to signalboost and back to
  signalc on the `trust` path

[#483] resolve "Support sealed sender messages"

Closes #483

See merge request !593

- we don't need it since accounts store their own profile keys as
  fields on account records in the account store!