Pass primaryIdentityPublicKeys.ed25519, signedIdentityKeysBlob.payload and signedIdentityKeysBlob.signature to olmUtil.ed25519_verify(...) to ensure that the signature is valid.
Depends on D6896
Paths
| Differential D6897 Authored by atul on Feb 25 2023, 1:18 AM.
Details Summary Pass primaryIdentityPublicKeys.ed25519, signedIdentityKeysBlob.payload and signedIdentityKeysBlob.signature to olmUtil.ed25519_verify(...) to ensure that the signature is valid. Depends on D6896 Test Plan I tested with a valid signature and observed that ed25519_verify(...) succeeded. I tested with an invalid signature ("blah"), and observed that olmUtil.ed25519(...) threw an exception.
Diff Detail
Event TimelineHarbormaster completed remote builds in B16906: Diff 23097.Feb 25 2023, 1:34 AM2023-02-25 01:34:14 (UTC-8) Comment Actions Nice! After this verification step, we should then JSON.parse(signedIdentityKeysBlob.payload) and run the result through an input validator. Then we'll be ready to store them in the DB. (Assume that's for a later diff, though.) Requesting changes for this:
We could probably just have a function getOlmUtility that returns a Promise that does lines 345 and 346 here, and caches the result. This revision now requires changes to proceed.Feb 26 2023, 5:49 AM2023-02-26 05:49:06 (UTC-8) Comment Actions
I'll need to make sure there that await olm.init(); is "idempotent" and there aren't any issues with calling it multiple times. Just want to make sure in the case where the keyserver gets multiple siwe_auth requests at the same time that calling await olm.init() simultaneously/multiple times doesn't break anything. atul retitled this revision from [DRAFT] Verify `signedIdentityKeysBlob` signature in `logInResponder` to [keyserver] Verify `signedIdentityKeysBlob` signature in `logInResponder`. Comment Actions
Doing this in separate diff (think it is "separate unit of work" and should be reviewed separately). I'll link here, but this can be landed without issue. Comment Actions
Ah yeah I get what you mean. You could address this by storing the promise in some variable, and then checking if the variable is already set with the promise. If so you would return the existing promise, if not you could call olm.init() to get the promise and set it. The core thing here is to avoid passing the promise to await before doing the caching... that's what introduces the possibility of a race. Comment Actions
Did you test calling await olm.init() multiple times? Comment Actions
Yup: This revision is now accepted and ready to land.Feb 27 2023, 1:41 PM2023-02-27 13:41:26 (UTC-8) This revision was landed with ongoing or failed builds.Feb 27 2023, 3:15 PM2023-02-27 15:15:04 (UTC-8) Closed by commit rCOMM76c64df43f92: [keyserver] Verify `signedIdentityKeysBlob` signature in `logInResponder` (authored by atul). · Explain Why This revision was automatically updated to reflect the committed changes. Harbormaster completed remote builds in B16963: Diff 23184.Feb 27 2023, 3:26 PM2023-02-27 15:26:05 (UTC-8)
Revision Contents
Diff 23185 keyserver/src/responders/user-responders.js
lib/types/account-types.js
lib/types/crypto-types.js
|
Do you think it would make sense to move this into authorization middleware? So you can specify something like
I don't remember exactly what the API for the reports service is, but right now this diff would allow everyone to "authenticate" to the reports service by just not providing credentials (and get the service token by default). This should probably be scoped per (group of) endpoints.