Page MenuHomePhabricator
Differential D9817

Add encryption order to encrypted notifications
ClosedPublic
Actions

Authored by marcin on Nov 10 2023, 5:41 AM.
Tags
None
Referenced Files
F5077850: D9817.id33544.diff
Fri, Mar 28, 11:45 PM
Unknown Object (File)
Thu, Mar 27, 5:57 AM
Unknown Object (File)
Thu, Mar 20, 9:49 PM
Unknown Object (File)
Wed, Mar 19, 12:28 PM
Unknown Object (File)
Tue, Mar 18, 11:15 AM
Unknown Object (File)
Tue, Mar 18, 11:15 AM
Unknown Object (File)
Tue, Mar 18, 11:14 AM
Unknown Object (File)
Tue, Mar 18, 11:14 AM
View All Files
Subscribers
ashoat
will

Details

Reviewers
kamil
michal
tomek
Commits
rCOMM923990a49ce8: Add encryption order to encrypted notifications
Summary

This differential add encryptionOrder field to result of encryption with olm session, which contains information about encryption ordering.

Test Plan

edit in web GUI

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

marcin created this revision.Nov 10 2023, 5:41 AM
Herald added subscribers: will, ashoat. · View Herald TranscriptNov 10 2023, 5:41 AM
Harbormaster completed remote builds in B23989: Diff 33063.Nov 10 2023, 6:01 AM
marcin requested review of this revision.Nov 10 2023, 6:01 AM
marcin updated this revision to Diff 33066.Nov 10 2023, 6:07 AM

rebase to update commit message

marcin added a parent revision: D9661: Decrypt encrypted web notifications in service worker.Nov 10 2023, 6:08 AM
marcin added a child revision: D9818: Refactor Windows push code to match conventions for other platforms.
Harbormaster completed remote builds in B23992: Diff 33066.Nov 10 2023, 6:38 AM
tomek accepted this revision.Nov 13 2023, 7:25 AM
tomek added inline comments.
keyserver/src/push/crypto.js
30 ↗(On Diff #33066)

Why is it optional?

This revision is now accepted and ready to land.Nov 13 2023, 7:25 AM
marcin added inline comments.Nov 13 2023, 8:25 AM
keyserver/src/push/crypto.js
30 ↗(On Diff #33066)

It is kept optional to handle the case of encryption failure, when ee can't assign it a meaningful value

marcin updated this revision to Diff 33544.Nov 23 2023, 2:07 AM

Rebase before landing

Harbormaster completed remote builds in B24364: Diff 33544.Nov 23 2023, 4:12 AM
Closed by commit rCOMM923990a49ce8: Add encryption order to encrypted notifications (authored by marcin). · Explain WhyNov 23 2023, 5:50 AM
This revision was automatically updated to reflect the committed changes.
marcin added a commit: rCOMM923990a49ce8: Add encryption order to encrypted notifications.

Revision Contents
Changeset List

PathSize
keyserver/
src/
push/
32 lines
1 line
3 lines
updaters/
3 lines

Diff 33063

View Options

keyserver/src/push/crypto.js

  • This file was added.
// @flow
import * as React from 'react';
import { type SetState } from 'lib/types/hook-types';
import { type RelationshipButton } from 'lib/types/relationship-types';
import { type ThreadInfo } from 'lib/types/thread-types';
import type { UserInfo } from 'lib/types/user-types';
import ThreadSettingsRelationshipButton from './thread-settings-relationship-button.react';
import css from './thread-settings-relationship-tab.css';
type Props = {
+threadSettingsOperationInProgress: boolean,
+threadInfo: ThreadInfo,
tomekUnsubmitted
Not Done
Inline Actions

These props aren't used. Shouldn't this give a warning?

tomek: These props aren't used. Shouldn't this give a warning?
jacekAuthorUnsubmitted
Done
Inline Actions

Interesting. I thought flow should indicate warning for such variables.

jacek: Interesting. I thought flow should indicate warning for such variables.
ashoatUnsubmitted
Not Done
Inline Actions

There can be a good reason for having a prop that you never use: to force the component to rerender. For instance, we do something similar here

ashoat: There can be a good reason for having a prop that you never use: to force the component to…
+setErrorMessage: SetState<string>,
+relationshipButtons: $ReadOnlyArray<RelationshipButton>,
+otherUserInfo: UserInfo,
};
function ThreadSettingsRelationshipTab(props: Props): React.Node {
const { relationshipButtons, otherUserInfo, setErrorMessage } = props;
const buttons = React.useMemo(() => {
return relationshipButtons.map(action => {
return (
<ThreadSettingsRelationshipButton
key={action}
relationshipButton={action}
otherUserInfo={otherUserInfo}
setErrorMessage={setErrorMessage}
tomekUnsubmitted
Not Done
Inline Actions

In ThreadSettingsRelationshipButton setErrorMessage is string => void but here we use SetState<string>. Is flow ok with that? Is there a good reason for having different types?

tomek: In `ThreadSettingsRelationshipButton` `setErrorMessage` is `string => void` but here we use…
jacekAuthorUnsubmitted
Done
Inline Actions

Flow is ok here. I'll replace the type in ...Button with SetState<string>

jacek: Flow is ok here. I'll replace the type in `...Button` with `SetState<string>`
/>
);
});
}, [otherUserInfo, relationshipButtons, setErrorMessage]);
return <div className={css.container}>{buttons}</div>;
}
export default ThreadSettingsRelationshipTab;
View Options

keyserver/src/push/rescind.js

  • This file was added.
// @flow
import * as React from 'react';
import { type SetState } from 'lib/types/hook-types';
import { type RelationshipButton } from 'lib/types/relationship-types';
import { type ThreadInfo } from 'lib/types/thread-types';
import type { UserInfo } from 'lib/types/user-types';
import ThreadSettingsRelationshipButton from './thread-settings-relationship-button.react';
import css from './thread-settings-relationship-tab.css';
type Props = {
+threadSettingsOperationInProgress: boolean,
+threadInfo: ThreadInfo,
tomekUnsubmitted
Not Done
Inline Actions

These props aren't used. Shouldn't this give a warning?

tomek: These props aren't used. Shouldn't this give a warning?
jacekAuthorUnsubmitted
Done
Inline Actions

Interesting. I thought flow should indicate warning for such variables.

jacek: Interesting. I thought flow should indicate warning for such variables.
ashoatUnsubmitted
Not Done
Inline Actions

There can be a good reason for having a prop that you never use: to force the component to rerender. For instance, we do something similar here

ashoat: There can be a good reason for having a prop that you never use: to force the component to…
+setErrorMessage: SetState<string>,
+relationshipButtons: $ReadOnlyArray<RelationshipButton>,
+otherUserInfo: UserInfo,
};
function ThreadSettingsRelationshipTab(props: Props): React.Node {
const { relationshipButtons, otherUserInfo, setErrorMessage } = props;
const buttons = React.useMemo(() => {
return relationshipButtons.map(action => {
return (
<ThreadSettingsRelationshipButton
key={action}
relationshipButton={action}
otherUserInfo={otherUserInfo}
setErrorMessage={setErrorMessage}
tomekUnsubmitted
Not Done
Inline Actions

In ThreadSettingsRelationshipButton setErrorMessage is string => void but here we use SetState<string>. Is flow ok with that? Is there a good reason for having different types?

tomek: In `ThreadSettingsRelationshipButton` `setErrorMessage` is `string => void` but here we use…
jacekAuthorUnsubmitted
Done
Inline Actions

Flow is ok here. I'll replace the type in ...Button with SetState<string>

jacek: Flow is ok here. I'll replace the type in `...Button` with `SetState<string>`
/>
);
});
}, [otherUserInfo, relationshipButtons, setErrorMessage]);
return <div className={css.container}>{buttons}</div>;
}
export default ThreadSettingsRelationshipTab;
View Options

keyserver/src/push/types.js

  • This file was added.
// @flow
import * as React from 'react';
import { type SetState } from 'lib/types/hook-types';
import { type RelationshipButton } from 'lib/types/relationship-types';
import { type ThreadInfo } from 'lib/types/thread-types';
import type { UserInfo } from 'lib/types/user-types';
import ThreadSettingsRelationshipButton from './thread-settings-relationship-button.react';
import css from './thread-settings-relationship-tab.css';
type Props = {
+threadSettingsOperationInProgress: boolean,
+threadInfo: ThreadInfo,
tomekUnsubmitted
Not Done
Inline Actions

These props aren't used. Shouldn't this give a warning?

tomek: These props aren't used. Shouldn't this give a warning?
jacekAuthorUnsubmitted
Done
Inline Actions

Interesting. I thought flow should indicate warning for such variables.

jacek: Interesting. I thought flow should indicate warning for such variables.
ashoatUnsubmitted
Not Done
Inline Actions

There can be a good reason for having a prop that you never use: to force the component to rerender. For instance, we do something similar here

ashoat: There can be a good reason for having a prop that you never use: to force the component to…
+setErrorMessage: SetState<string>,
+relationshipButtons: $ReadOnlyArray<RelationshipButton>,
+otherUserInfo: UserInfo,
};
function ThreadSettingsRelationshipTab(props: Props): React.Node {
const { relationshipButtons, otherUserInfo, setErrorMessage } = props;
const buttons = React.useMemo(() => {
return relationshipButtons.map(action => {
return (
<ThreadSettingsRelationshipButton
key={action}
relationshipButton={action}
otherUserInfo={otherUserInfo}
setErrorMessage={setErrorMessage}
tomekUnsubmitted
Not Done
Inline Actions

In ThreadSettingsRelationshipButton setErrorMessage is string => void but here we use SetState<string>. Is flow ok with that? Is there a good reason for having different types?

tomek: In `ThreadSettingsRelationshipButton` `setErrorMessage` is `string => void` but here we use…
jacekAuthorUnsubmitted
Done
Inline Actions

Flow is ok here. I'll replace the type in ...Button with SetState<string>

jacek: Flow is ok here. I'll replace the type in `...Button` with `SetState<string>`
/>
);
});
}, [otherUserInfo, relationshipButtons, setErrorMessage]);
return <div className={css.container}>{buttons}</div>;
}
export default ThreadSettingsRelationshipTab;
View Options

keyserver/src/updaters/olm-session-updater.js

  • This file was added.
// @flow
import * as React from 'react';
import { type SetState } from 'lib/types/hook-types';
import { type RelationshipButton } from 'lib/types/relationship-types';
import { type ThreadInfo } from 'lib/types/thread-types';
import type { UserInfo } from 'lib/types/user-types';
import ThreadSettingsRelationshipButton from './thread-settings-relationship-button.react';
import css from './thread-settings-relationship-tab.css';
type Props = {
+threadSettingsOperationInProgress: boolean,
+threadInfo: ThreadInfo,
tomekUnsubmitted
Not Done
Inline Actions

These props aren't used. Shouldn't this give a warning?

tomek: These props aren't used. Shouldn't this give a warning?
jacekAuthorUnsubmitted
Done
Inline Actions

Interesting. I thought flow should indicate warning for such variables.

jacek: Interesting. I thought flow should indicate warning for such variables.
ashoatUnsubmitted
Not Done
Inline Actions

There can be a good reason for having a prop that you never use: to force the component to rerender. For instance, we do something similar here

ashoat: There can be a good reason for having a prop that you never use: to force the component to…
+setErrorMessage: SetState<string>,
+relationshipButtons: $ReadOnlyArray<RelationshipButton>,
+otherUserInfo: UserInfo,
};
function ThreadSettingsRelationshipTab(props: Props): React.Node {
const { relationshipButtons, otherUserInfo, setErrorMessage } = props;
const buttons = React.useMemo(() => {
return relationshipButtons.map(action => {
return (
<ThreadSettingsRelationshipButton
key={action}
relationshipButton={action}
otherUserInfo={otherUserInfo}
setErrorMessage={setErrorMessage}
tomekUnsubmitted
Not Done
Inline Actions

In ThreadSettingsRelationshipButton setErrorMessage is string => void but here we use SetState<string>. Is flow ok with that? Is there a good reason for having different types?

tomek: In `ThreadSettingsRelationshipButton` `setErrorMessage` is `string => void` but here we use…
jacekAuthorUnsubmitted
Done
Inline Actions

Flow is ok here. I'll replace the type in ...Button with SetState<string>

jacek: Flow is ok here. I'll replace the type in `...Button` with `SetState<string>`
/>
);
});
}, [otherUserInfo, relationshipButtons, setErrorMessage]);
return <div className={css.container}>{buttons}</div>;
}
export default ThreadSettingsRelationshipTab;