-
Notifications
You must be signed in to change notification settings - Fork 333
[FS-919] Support Basic Processing of External Commits #2765
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
2db5319
to
70a607f
Compare
d0f0b69
to
9a1c4c4
Compare
a3ff2ce
to
bc0b9af
Compare
bc0b9af
to
937f13a
Compare
937f13a
to
62e5bdf
Compare
62e5bdf
to
61b5bab
Compare
61b5bab
to
e6beea8
Compare
- Extract the key package from the update path
e6beea8
to
38ae3ef
Compare
38ae3ef
to
c69966d
Compare
Just cli -> pure $ updateKeyPackageMapping lconv qusr cli (Just senderRef) updatedRef | ||
Nothing -> pure $ pure () | ||
(_, Nothing) -> pure $ pure () -- ignore commits without update path | ||
Just cli -> pure (updateKeyPackageMapping lconv qusr cli (Just senderRef) updatedRef, action) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would moving pure
outside of the case match work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it would. At first it looked weird to me as well. All the branches of the bigger pattern-match have to have the same type. As far as my understanding goes, this block is written this way so it can be executed later, but then I suppose the same could have been achieved if at the top we had a let
binding instead of monadic binding and using one level of monads less.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine either way, more of a nitpick :D
paRemove :: ClientMap, | ||
-- The backend does not process external init proposals, but still it needs | ||
-- to know if a commit has one when processing external commits | ||
paExternalInit :: Maybe () |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This Maybe ()
is pretty weird. Can we use Any
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, done in commit 20162df. But aren't these two types isomorphic as well, i.e., don't the same arguments you had yesterday in the call apply to Any
as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What arguments? My only argument here is that Maybe ()
is a circuitous way to express a boolean, while Any
is more direct. Using Bool
there is also fine. It's a minor thing, anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I see your point.
throwS @'MLSRemovalUserMismatch | ||
pure (Just r) | ||
|
||
updateKeyPackageMapping lconv qusr (ciClient cid) remRef newRef |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't you validate the key package first? See for example applyProposal
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your observation has seemed valid and with that in mind, I looked at other cases when a key package is updated or mapped and then some of them seemed equally wrong because they also just call updateKeyPackageMapping
. For example, in the case of an existing member updating their key package via the update path we blindly accept the new key package without checking if it is for the same protocol, same cipher suite, etc., but this seems wrong, doesn't it?
I realized updateKeyPackageMapping
does validation (the ciphersuite, identity matching, signature scheme, etc.) if the old key package is non-existent (i.e., we pass in Nothing
to updateKeyPackageMapping
), by calling an internal endpoint in Brig, for which there's a handler upsertKeyPackage
.
So before making a call to updateKeyPackageMapping
in the case of a NewMemberSender
, I just added a call to addKeyPackageRef
, which calls upsertKeyPackage
in Brig and validates it before inserting into the database.
Does that seem OK?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As long as validation is happening.
* Check external commit criteria - Extract the key package from the update path - Validate key package before replacing the old one * Fix the serialiseMLS instance for `Sender 'MLSPlainText` * Update the mls-test-cli reference * Integration tests for external commits
The PR introduces basic support for external commits in MLS. Note that this does not resubmit external pending proposals submitted by the backend; this is to be done in https://wearezeta.atlassian.net/browse/FS-920.
Tracked by https://wearezeta.atlassian.net/browse/FS-919.
Checklist
changelog.d