signalboost issueshttps://0xacab.org/team-friendo/signalboost/-/issues2021-06-14T19:48:06Zhttps://0xacab.org/team-friendo/signalboost/-/issues/463sc: migrate signald data store to signalc2021-06-14T19:48:06Zaguestusersc: migrate signald data store to signalc# notes on data migration implementation
- use kotlin for JSON parse
- make fixture from real signald JSON (dev)
- unit test against migrating from JSON to postgres
- extend `migrate` func to crawl directory and migrate many JSON blobs (...# notes on data migration implementation
- use kotlin for JSON parse
- make fixture from real signald JSON (dev)
- unit test against migrating from JSON to postgres
- extend `migrate` func to crawl directory and migrate many JSON blobs (needs less testing)
- make this `migrateDiredctory` an entrypoint that is run by a gradle task
- run gradle task in dev env, see if it is possible to run signalc stack against old signalboost numbers
- feel good about shipping!signalc mvpaguestuseraguestuserhttps://0xacab.org/team-friendo/signalboost/-/issues/419singalc: prelaunch manual QA2021-06-02T22:41:58Zaguestusersingalc: prelaunch manual QA- [ ] does trusting a new safety number work? (aguestuser replaced what looked like bad deserialization of hex-encoded byte array in `SocketReceiver#trust` but was unable to test that he could recover from reinstalling signal b/c of bein...- [ ] does trusting a new safety number work? (aguestuser replaced what looked like bad deserialization of hex-encoded byte array in `SocketReceiver#trust` but was unable to test that he could recover from reinstalling signal b/c of being in borked dev env statesignalc mvphttps://0xacab.org/team-friendo/signalboost/-/issues/502review !599, !601 (fixup)2021-06-26T00:23:15Zaguestuserreview !599, !601 (fixup)https://0xacab.org/team-friendo/signalboost/-/issues/499move boostit back to community instance2021-06-03T14:34:20Zaguestusermove boostit back to community instancehttps://0xacab.org/team-friendo/signalboost/-/issues/497review !5962021-06-03T02:44:46Zaguestuserreview !596feed backfeed backhttps://0xacab.org/team-friendo/signalboost/-/issues/496sc: recover from ex-subscriber re-subscribing2021-06-03T14:35:37Zfeed backsc: recover from ex-subscriber re-subscribing# context
- we want to be able to delete user data from the protocol store (identity/session) when they unsusbscribe to our channels
- to do this safely, we need to be able to recover a valid id and session if an unsubscribed user tries ...# context
- we want to be able to delete user data from the protocol store (identity/session) when they unsusbscribe to our channels
- to do this safely, we need to be able to recover a valid id and session if an unsubscribed user tries to subscribe again (but we deleted all their session data)
- a signalc accouht *can* reconstruct a valid session with a contact but ONLY if it initiates the session with an outgoing message. (incoming messages generate errors of the type below)
- SO! in this MR, we will handle the error generated by an incoming message from an unsubscribed user by responding with a message that will reconstruct a valid session and identity
# behavior:
stub!
GIVEN i have unsubscrbied (and have no data in signalc store)
* WHEN i send a HELLO
* THEN i see a message that says (something like) "Sorry, we just had to do some crypto-crypto blah blah to talk to you again. Please resend!"
* WHEN i send HELLO again
* THEN i am resubscribed as normal
# implementation notes:
- this is the error we have to handle
```
signalc_signalboost | {"type":"decryption_error","sender":{"number":"+16154804259","uuid":"362feb8e-17a0-402b-92d8-773df1b38a74"},"recipient":{"number":"+19096711587","uuid":"842cd970-9575-4a27-b10b-299c8f6ab551"},"error":{"cause":"java.lang.IllegalStateException","message":"invalid state for call to session_state to succeed: No session"}}----------------
signalc_signalboost |
signalc | 2021-06-02 16:39:39.611 [i.s.s.l.SignalReceiver] ERROR | Decryption Error:
signalc | java.lang.IllegalStateException: invalid state for call to session_state to succeed: No session
signalc | at org.signal.client.internal.Native.SessionCipher_DecryptSignalMessage(Native Method)
signalc | at org.whispersystems.libsignal.SessionCipher.decrypt(SessionCipher.java:126)
signalc | at org.whispersystems.signalservice.api.crypto.SignalServiceCipher.decrypt(SignalServiceCipher.java:185)
signalc | at org.whispersystems.signalservice.api.crypto.SignalServiceCipher.decrypt(SignalServiceCipher.java:138)
signalc | at info.signalboost.signalc.logic.SignalReceiver$relay$2.invokeSuspend(SignalReceiver.kt:188)
signalc | at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
signalc | at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
signalc | at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
signalc | at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
signalc | at java.base/java.lang.Thread.run(Thread.java:834)
```https://0xacab.org/team-friendo/signalboost/-/issues/495review !5932021-06-01T23:10:42Zaguestuserreview !593just this once we are allowing ourselves post-merge review to alleviate some git-snarls in ongoing work. but here look! we have a card to make sure we do review on this complicated work!
the MR is !593just this once we are allowing ourselves post-merge review to alleviate some git-snarls in ongoing work. but here look! we have a card to make sure we do review on this complicated work!
the MR is !593feed backfeed backhttps://0xacab.org/team-friendo/signalboost/-/issues/481load: modify harness to track arbitrary Signal-Server versions2021-06-03T15:45:11Zfeed backload: modify harness to track arbitrary Signal-Server versions- Try and rip out all patches (we don't think they are necessary)
- Remove config generator
- Fetch generated config from current signal server and place in our repo to mount
- Update Dockerfile for signal server to reflect the above,...- Try and rip out all patches (we don't think they are necessary)
- Remove config generator
- Fetch generated config from current signal server and place in our repo to mount
- Update Dockerfile for signal server to reflect the above, and pin to a specific version of signal server
- Update docker-compose to mount the generated confighttps://0xacab.org/team-friendo/signalboost/-/issues/478bug: signalc receiver decryption errors in loadtest2021-06-03T15:51:51Zaguestuserbug: signalc receiver decryption errors in loadtestas of sometime last week we started observing an error in which `receiver_signalc` always throws decryption errors on every message it receives from the `sender_signalc`. we do *not* observe such errors when using signalc in dev to talk ...as of sometime last week we started observing an error in which `receiver_signalc` always throws decryption errors on every message it receives from the `sender_signalc`. we do *not* observe such errors when using signalc in dev to talk to normal phones using the normal signal server.
things that are different:
- (1) our phones are not running signalc (unlike loadtest receivers)
- (2) signalc is using real signal server to talk to our phones (unlike fake signal server in loadtests)
error:
```
0000000000) to +10000000007
2021-05-10 20:30:07.760 [i.s.s.l.SignalReceiver] DEBUG | Got PREKEY_BUNDLE from Optional.of(+20000000000) to +10000000002
2021-05-10 20:30:07.760 [i.s.s.l.SignalReceiver] DEBUG | Got PREKEY_BUNDLE from Optional.of(+20000000000) to +10000000002
# snip #
2021-05-10 20:30:08.001 [i.s.s.l.SignalReceiver] ERROR | Decryption Error:
org.signal.libsignal.metadata.ProtocolInvalidMessageException: org.whispersystems.libsignal.InvalidMessageException: Message from +20000000000:1 failed to decrypt; sender ratchet public key 47ef9fee16172c744c2da928c41e39d70b8a6496325a34c9b25dbb5f9eee6b40 message counter 6
Candidate session 0 failed with 'invalid ciphertext message', had 0 receiver chains
at org.whispersystems.signalservice.api.crypto.SignalServiceCipher.decrypt(SignalServiceCipher.java:210)
at org.whispersystems.signalservice.api.crypto.SignalServiceCipher.decrypt(SignalServiceCipher.java:138)
at info.signalboost.signalc.logic.SignalReceiver$relay$2.invokeSuspend(SignalReceiver.kt:170)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.whispersystems.libsignal.InvalidMessageException: Message from +20000000000:1 failed to decrypt; sender ratchet public key 47ef9fee16172c744c2da928c41e39d70b8a6496325a34c9b25dbb5f9eee6b40 message counter 6
Candidate session 0 failed with 'invalid ciphertext message', had 0 receiver chains
at org.signal.client.internal.Native.SessionCipher_DecryptPreKeySignalMessage(Native Method)
at org.whispersystems.libsignal.SessionCipher.decrypt(SessionCipher.java:100)
at org.whispersystems.signalservice.api.crypto.SignalServiceCipher.decrypt(SignalServiceCipher.java:178)
... 7 more
```https://0xacab.org/team-friendo/signalboost/-/issues/436[harden] add password for postgres db2021-03-24T14:20:42Zaguestuser[harden] add password for postgres db# context
* an attacker on the box can easily get this password (which is why we don't have it currently)
* however, if we assume an attack trying to use the postgres container itself as a point of entry, this provides useful defense in ...# context
* an attacker on the box can easily get this password (which is why we don't have it currently)
* however, if we assume an attack trying to use the postgres container itself as a point of entry, this provides useful defense in depthfeed backfeed backhttps://0xacab.org/team-friendo/signalboost/-/issues/405count redeemed/auto-deleted channels in prometheus2020-12-09T01:47:14Zaguestusercount redeemed/auto-deleted channels in prometheus# context
- when we were first building the auto-delete feature, it was helpful to be notified when people redeemed their channels and/or channels were deleted (1) to make sure the timing aspects of the feature worked as expected, (2) to...# context
- when we were first building the auto-delete feature, it was helpful to be notified when people redeemed their channels and/or channels were deleted (1) to make sure the timing aspects of the feature worked as expected, (2) to get a sense of what percentage of people redeemed their channels
- now that we know the feature works, the notifications deliver less value. since we prompt admins to delete their channels more frequently (every week), we also get a lot of low-value notifications, leading to alert fatigue
- this MR would replace notifications with a prometheus counter metric, allowing us to track redemptions vs. deletions over time without wasting alerts to do so
# behavior
GIVEN a channel scheduled for auto-deletion due to lack of use
- WHEN the admin redeems the channel
- THEN the system increments a `channel_redeemed` counter
GIVEN a channel scheduled for auto-deletion due to lack of use
- WHEN nobody redeems the channel and it is deleted
- THEN they system increments a `channel_auto_deleted` counter
WHEN a maintainer logs into our grafana dash
- THEN they will see a graph comparing redemptions to auto-deletions over time