This differential implements creating as passing a signature of concatenated olm identity keys to JS.
Details
Details
Modify any place in JS where CommCoreModule.initializeCryptoAccount is called, by loggind ed25519Signature.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- marcin/eng-2901
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| native/cpp/CommonCpp/NativeModules/CommCoreModule.cpp | ||
|---|---|---|
| 848 | cc @ashoat, @atul {
notifCurve25519: xxxxx...,
ed25519: xxxxx....,
} | |
| native/cpp/CommonCpp/NativeModules/CommCoreModule.cpp | ||
|---|---|---|
| 848 | Yeah, we should do a JSON blob. I responded on the Linear issue | |
Comment Actions
Here's what the message/payload looks like on the web side:
{ "primaryIdentityPublicKeys": { "ed25519": "bbuak18zkZDrvV/kpzYx02LOfNu/A8WN9OPdida0HXU", "curve25519": "LdX2vxtgffJod2I2voieKqEuTW5ZUpmP/XbTy5ksJns" }, "notificationIdentityPublicKeys": { "ed25519": "7uiRAOqZe0HwzaG6/KXy8zDrT8713Anezvw8aGlAhXg", "curve25519": "kafUrgUra6qy4t3xv3AefAMad8241uklNzDXPCDzAgM" } }
That stringified payload gets bundled with the signature into type SignedIdentityKeysBlob:
which looks something like this:
{ "payload": "{\"primaryIdentityPublicKeys\":{\"ed25519\":\"Ok3f6Wypanf674HlCrL5KvWijFMakLTrSox61Nje6A0\",\"curve25519\":\"TygagUrYYw22ckucuEMCtQRfeANsHDoHPOpIvU9n4xk\"},\"notificationIdentityPublicKeys\":{\"ed25519\":\"vV4ATS5QT1qXnyMx/YiPU/Hncj8tgeNeRvWee9kQRTM\",\"curve25519\":\"78fhUKKAVrKwuIzRJpezbOxeFB4yytO0OE3f6t6HAhI\"}}", "signature": "pdvLQxeTPX8ATKjv8vp2K2C7RzfJX6IkEnk81KZVCNvX+2yu5qgouSIdXSnu1dNbany0+rh8nJZhDVbUMQvEAQ" }
Comment Actions
This comment has been deleted.
| native/cpp/CommonCpp/NativeModules/CommCoreModule.cpp | ||
|---|---|---|
| 843 ↗ | (On Diff #23328) | This code has serious issues and should have never been landed, and is the reason behind ENG-3242, an Urgent issue where we shipped a crash-on-log-in to prod. A basic issue is that we're proceeding through this block even if we failed to set primaryKeysResult and instead set error. A second issue is that we aren't wrapping our calls to parseJson and aren't checking for errors. This wouldn't be a problem if it wasn't for the first issue, but it's always good practice to catch exceptions for parseJson. (This was initially introduced by @atul in D6115, and I should've called it out there.) It's not clear to me why it works on iOS but doesn't on Android. Outside of the poor error-handling behavior as noted above, there is a third issue: why are we seeing errors on Android at all? |
| native/cpp/CommonCpp/NativeModules/CommCoreModule.cpp | ||
|---|---|---|
| 843 ↗ | (On Diff #23328) |
I was passing the JSON blob from OLM's identity_keys() directly to folly::parseJson(...) which I trusted (and still trust) would be valid JSON as long as generateIdentityKeys completed successfully (didn't throw an error):  The code has changed significantly since then. |