- 13 Sep, 2021 1 commit
-
-
aguestuser authored
-
- 20 Aug, 2021 2 commits
-
-
aguestuser authored
[splash] remove link to wayback machine archive (pending signoff) See merge request !604
-
aguestuser authored
-
- 19 Aug, 2021 2 commits
-
-
aguestuser authored
[splash] replace splash site with shutdown notice See merge request !603
-
aguestuser authored
-
- 12 Jul, 2021 2 commits
-
-
Mari authored
- 26 Jun, 2021 2 commits
-
-
aguestuser authored
[hf] fixup mr !599 - cleanup SignalReceiver/ContactStore See merge request !601
-
aguestuser authored
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)
-
- 24 Jun, 2021 14 commits
-
-
aguestuser authored
[#498] Resolve contact ids Closes #498 See merge request !599
-
aguestuser authored
-
aguestuser authored
-
aguestuser authored
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
-
aguestuser authored
-
aguestuser authored
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`
-
aguestuser authored
-
aguestuser authored
(necessary to make removal of non-null constraint safe)
-
aguestuser authored
-
aguestuser authored
-
aguestuser authored
- 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)
-
aguestuser authored
-
aguestuser authored
-
aguestuser authored
- (this is needed to create sessions with actual contacts for reasons that remain unclear!)
-
- 18 Jun, 2021 1 commit
-
-
aguestuser authored
-
- 16 Jun, 2021 9 commits
-
-
aguestuser authored
-
aguestuser authored
-
aguestuser authored
-
aguestuser authored
- 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.
-
aguestuser authored
- 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)
-
aguestuser authored
-
aguestuser authored
[hf] add docs for running 2 signal installations on 1 device See merge request !600
-
aguestuser authored
-
- 10 Jun, 2021 2 commits
-
-
Mari authored
- 07 Jun, 2021 2 commits
-
-
aguestuser authored
[hotfix] handle signal verification codes with or without hyphens See merge request !595
-
-
- 03 Jun, 2021 3 commits
-
-
aguestuser authored
[#493] modify identity store to store one identity key per contact Closes #493 See merge request !596
-
aguestuser authored
-
aguestuser authored
- 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!
-