forked from openmls/openmls
-
Notifications
You must be signed in to change notification settings - Fork 1
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
Add Mutable and Immutable Metadata #17
Merged
Merged
Changes from all commits
Commits
Show all changes
18 commits
Select commit
Hold shift + click to select a range
1d32ea3
Process GroupContextExtensions Proposals (#1475)
keks 4d5716e
Add leaf node configuration options to MlsGroup builder (#1477)
kkohbrok 0d67da8
Clean up `MlsGroup*` builders (#1478)
kkohbrok 303967c
Enable the use of unknown/opaque extensions (#1479)
kkohbrok 8c72541
Merge remote-tracking branch 'openmls/main'
keks cbb4c11
Add first draft of mutable metadata extension
keks b646b47
rename to Metadata, add test
keks acfbee2
add comments
keks 09f1832
change ProtectedMetadata extension id to 0xf002
keks f94a4c2
update test that assumed 0xf000 was an unknown extension
keks ed849bd
fixup after merge from upstream main
franziskuskiefer b184e1a
rename to immutable metadata
franziskuskiefer f6503ce
reject if there was no immutable metadata before
franziskuskiefer d7e059a
simplify validation
keks cd91f6c
add test
keks 305b761
address feedback
keks 17989cf
remove Metadata extension in favour of using Unknown extensions
keks cbf2b71
fix doc link
keks File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,23 @@ | ||
use super::{Deserialize, Serialize}; | ||
use tls_codec::{TlsDeserialize, TlsSerialize, TlsSize}; | ||
|
||
/// Metadata is an extension that keeps arbitrary application-specific metadata, in the form of a | ||
/// byte sequence. The application is responsible for specifying a format and parsing the contents. | ||
#[derive( | ||
PartialEq, Eq, Clone, Debug, Serialize, Deserialize, TlsDeserialize, TlsSerialize, TlsSize, | ||
)] | ||
pub struct Metadata { | ||
metadata: Vec<u8>, | ||
} | ||
|
||
impl Metadata { | ||
/// Create a new [`Metadata`] extension. | ||
pub fn new(metadata: Vec<u8>) -> Self { | ||
Self { metadata } | ||
} | ||
|
||
/// Get the metadata bytes. | ||
pub fn metadata(&self) -> &Vec<u8> { | ||
&self.metadata | ||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Supporting arbitrary extensions in the GroupContext is not RFC compliant. Extensions in the GroupContext need to be supported by every member (ie, also have an indication of support in their
capabilities
field).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.
Why do you think that's not RFC compliant?
Indicating support in capabilities if of course required. But MLS does not restrict extensions. In the contrary, implementations are supposed to handle any (unknown) extension gracefully. That's what the grease mechanisms tries to ensure.
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.
It says in section 13.4:
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.
Is the documentation a mis-statement, or does openmls actually allow arbitrary GroupContext extensions?
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.
It allows arbitrary group context extension, as long as all members support them.
As such, it is compliant with the RFC. The difference to other extensions is that the MLS implementation isn't aware of them. But it doesn't need to be as long as they are only relevant for the application. This way using especially private extension (0xF000 - 0xFFFF) becomes much easier, because the protocol implementation doesn't need to be made aware of them.
That said, @keks found an issue in the validation check for this (see openmls#1487). This is part of the larger effort of getting all validation checks into OpeMLS (see the validation label for some of them).