Page MenuHomePhabricator
Differential D7860 Diff 26634 keyserver/src/socket/session-utils.js

Changeset View

Standalone View

View Options

keyserver/src/socket/session-utils.js

Show All 35 Lines
import { hash } from 'lib/utils/objects.js'; import { hash } from 'lib/utils/objects.js';
import { promiseAll } from 'lib/utils/promises.js'; import { promiseAll } from 'lib/utils/promises.js';
import { import {
tShape, tShape,
tPlatform, tPlatform,
tPlatformDetails, tPlatformDetails,
} from 'lib/utils/validation-utils.js'; } from 'lib/utils/validation-utils.js';
import { createOlmSession } from '../creators/olm-session-creator.js';
import { saveOneTimeKeys } from '../creators/one-time-keys-creator.js'; import { saveOneTimeKeys } from '../creators/one-time-keys-creator.js';
import createReport from '../creators/report-creator.js'; import createReport from '../creators/report-creator.js';
import { SQL } from '../database/database.js'; import { SQL } from '../database/database.js';
import { import {
fetchEntryInfos, fetchEntryInfos,
fetchEntryInfosByID, fetchEntryInfosByID,
fetchEntriesForSession, fetchEntriesForSession,
} from '../fetchers/entry-fetchers.js'; } from '../fetchers/entry-fetchers.js';
▲ Show 20 Lines • Show All 74 Lines • ▼ Show 20 Linesconst clientResponseInputValidator: TUnion<ClientResponse> = t.union([
}), }),
tShape({ tShape({
type: t.irreducible( type: t.irreducible(
'serverRequestTypes.SIGNED_IDENTITY_KEYS_BLOB', 'serverRequestTypes.SIGNED_IDENTITY_KEYS_BLOB',
x => x === serverRequestTypes.SIGNED_IDENTITY_KEYS_BLOB, x => x === serverRequestTypes.SIGNED_IDENTITY_KEYS_BLOB,
), ),
signedIdentityKeysBlob: signedIdentityKeysBlobValidator, signedIdentityKeysBlob: signedIdentityKeysBlobValidator,
}), }),
tShape({
type: t.irreducible(
'serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE',
tomekUnsubmitted
Not Done
Inline Actions

I know this approach was used earlier, but isn't it just tString(serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE)?

tomek: I know this approach was used earlier, but isn't it just `tString(serverRequestTypes.
marcinAuthorUnsubmitted
Done
Inline Actions

I am not sure if that is what you were thinking about but an attempt to use it in the following way:

tShape({
   type: t.String(serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE),
   initialNotificationsEncryptedMessage: t.String,
 }),

results in flow error:

Error ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ src/socket/session-utils.js:136:13

Cannot call t.String because a call signature declaring the expected parameter / return type is missing in
TIrreducible [1]. [prop-missing]

     src/socket/session-utils.js
     133│     signedIdentityKeysBlob: signedIdentityKeysBlobValidator,
     134│   }),
     135│   tShape({
     136│     type: t.String(serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE),
     137│     initialNotificationsEncryptedMessage: t.String,
     138│   }),
     139│ ]);

     ../lib/flow-typed/npm/tcomb_v3.x.x.js
 [1] 110│     +String: TIrreducible<string>,
Found 1 error
marcin: I am not sure if that is what you were thinking about but an attempt to use it in the following…
x => x === serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE,
),
initialNotificationsEncryptedMessage: t.String,
}),
]); ]);
type StateCheckStatus = type StateCheckStatus =
| { status: 'state_validated' } | { status: 'state_validated' }
| { status: 'state_invalid', invalidKeys: $ReadOnlyArray<string> } | { status: 'state_invalid', invalidKeys: $ReadOnlyArray<string> }
| { status: 'state_check' }; | { status: 'state_check' };
type ProcessClientResponsesResult = { type ProcessClientResponsesResult = {
serverRequests: ServerServerRequest[], serverRequests: ServerServerRequest[],
▲ Show 20 Lines • Show All 83 Lines • ▼ Show 20 Lines ) {
setCookieSignedIdentityKeysBlob( setCookieSignedIdentityKeysBlob(
viewer.cookieID, viewer.cookieID,
signedIdentityKeysBlob, signedIdentityKeysBlob,
), ),
); );
} catch (e) { } catch (e) {
continue; continue;
} }
} else if (
clientResponse.type ===
serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE
) {
invariant(
clientResponse.initialNotificationsEncryptedMessage,
'initialNotificationsEncryptedMessage expected in client response',
);
tomekUnsubmitted
Not Done
Inline Actions

It would be better if it was verified using tComb validator

tomek: It would be better if it was verified using `tComb` validator
const { initialNotificationsEncryptedMessage } = clientResponse;
try {
await createOlmSession(
initialNotificationsEncryptedMessage,
'notifications',
tomekUnsubmitted
Not Done
Inline Actions

What is the meaning of this value?

tomek: What is the meaning of this value?
marcinAuthorUnsubmitted
Done
Inline Actions

The keyserver has to olm accounts: one for notifications and the other for communication with identity service. createOlmSession can be used to create session for both of this accounts. This argument informs which olm account we will use to create olm session. In this particular case we will use olm accounts for e2e notifications.

marcin: The keyserver has to olm accounts: one for notifications and the other for communication with…
viewer.cookieID,
);
} catch (e) {
continue;
}
tomekUnsubmitted
Not Done
Inline Actions

Is it safe to ignore the exception? Would the client ever know that something went wrong?

tomek: Is it safe to ignore the exception? Would the client ever know that something went wrong?
marcinAuthorUnsubmitted
Done
Inline Actions

I think it si for three reasones:

  1. It has already been used for other requests and proved to work.
  2. If it fails, the keyserver will re-attempt to retrieve this data from the client.
  3. If this fails due to some permanent db failure we will be informed by prepareEncryptedIOSNotifications function that we are constantly missing olm session for a client that has code version high enough to handle notification encryption.
  4. The client code in this stack is implemented in a way that it is aware of a case when notifications are delivered unencrypted. When this issue: https://linear.app/comm/issue/ENG-2670/c-equivalent-of-dev-flag#comment-45f70230 is resolved staff members will be informed that their notifications are delivered unencrypted.

Until the linear issue mentioned above is not resolved we don't really have a proper way to handle such failure on the client.

marcin: I think it si for three reasones: 1. It has already been used for other requests and proved to…
} }
} }
const activityUpdatePromise = (async () => { const activityUpdatePromise = (async () => {
if (activityUpdates.length === 0) { if (activityUpdates.length === 0) {
return undefined; return undefined;
} }
return await activityUpdater(viewer, { updates: activityUpdates }); return await activityUpdater(viewer, { updates: activityUpdates });
▲ Show 20 Lines • Show All 361 Lines • Show Last 20 Lines