Merge remote-tracking branch 'upstream/main' into 10-08-merge_upstream

Author: richardhuaaa

.github/ISSUE_TEMPLATE/bug_report.md

@@ -3,37 +3,43 @@ name: Bug report
 about: Create a report to help us improve
 title: "[Bug]"
 labels: bug
-assignees: ''
-
+assignees: ""
 ---
 
 <!-- The issue tracker is ONLY used for reporting bugs, feature requests, and spec changes. For support or discussions please use https://github.com/openmls/openmls/discussions or https://openmls.zulipchat.com/. -->
 
 **Describe the bug**
+
 <!-- A clear and concise description of what the bug is. -->
 
 **To Reproduce**
-<!-- 
+
+<!--
 Steps to reproduce the behavior:
 1. Use the following API call/function: ...
 2. See error
 -->
 
 **Expected behavior**
+
 <!-- A clear and concise description of what you expected to happen. -->
 
 **Actual behavior**
+
 <!-- A brief explanation of what happens instead. -->
 
 **Screenshots or debug log**
+
 <!-- If applicable, add screenshots or debug logs to help explain your problem. -->
 
 **Platform (please complete the following information):**
-<!-- 
+
+<!--
  - OS & OS version: [e.g. macOS 11.0.1]
  - Architecture [e.g. x86_64]
  - Version [e.g. v0.2]
 -->
 
 **Additional context**
+
 <!-- Add any other context about the problem here. -->

.github/ISSUE_TEMPLATE/feature_request.md

@@ -3,20 +3,23 @@ name: Feature request
 about: Suggest an idea for this project
 title: "[Feature request]"
 labels: enhancement
-assignees: ''
-
+assignees: ""
 ---
 
 <!-- The issue tracker is ONLY used for reporting bugs, feature requests, and spec changes. For support or discussions please use https://github.com/openmls/openmls/discussions or https://openmls.zulipchat.com/. -->
 
 **Is your feature request related to a problem? Please describe.**
+
 <!-- A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] -->
 
 **Describe the solution you'd like**
+
 <!-- A clear and concise description of what you want to happen. -->
 
 **Describe alternatives you've considered**
+
 <!-- A clear and concise description of any alternative solutions or features you've considered. -->
 
 **Additional context**
+
 <!-- Add any other context or screenshots about the feature request here. -->

.github/ISSUE_TEMPLATE/mls-spec-change.md

@@ -3,14 +3,15 @@ name: MLS spec change
 about: Changes in the MLS protocol/architecture document
 title: "[MLS Spec change]"
 labels: mls-spec change
-assignees: ''
-
+assignees: ""
 ---
 
 <!-- The issue tracker is ONLY used for reporting bugs, feature requests, and spec changes. For support or discussions please use https://github.com/openmls/openmls/discussions or https://openmls.zulipchat.com/. -->
 
 **Description of the changes**
+
 <!-- Explain what the changes are about. -->
 
 **Link to the exact changes**
+
 <!-- Please provide a link to the PR on [https://github.com/mlswg] -->

CHANGELOG.md

@@ -7,7 +7,10 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## Unreleased
 
+## 0.7.1 (2025-09-24)
+
 ### Added
+
 - [#1801](https://github.com/openmls/openmls/pull/1801): Added `MlsGroup::external_commit_builder`.
 - [#1814](https://github.com/openmls/openmls/pull/1814): Allow disabling leaf node lifetime validation in the ratchet tree when joining a group.
   - `StagedWelcome::build_from_welcome`: Alternative to `new_from_welcome` in a builder style that allows disabling lifetime validation of the incoming ratchet tree.
@@ -17,12 +20,16 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - [#1840](https://github.com/openmls/openmls/pull/1840): Add `has_pending_proposals` getter method to `MlsGroup`.
 
 ### Fixed
+
 - [#1846](https://github.com/openmls/openmls/pull/1846): Fix persistence during message processing by properly persisting the secret tree after processing private messages and improve forward secrecy within epochs.
 
 ### Changed
+
 - [#1846](https://github.com/openmls/openmls/pull/1846): Processing messages in `MlsGroup` and `PublicGroup` now returns two different error types: `ProcessMessageError` and `PublicProcessMessageError`. `ProcessMessageError` now includes a storage error variant and `PublicProcessMessageError` no longer includes the `GroupStateError` variant.
+- [#1851](https://github.com/openmls/openmls/pull/1851): The GroupInfos in Welcome messages no longer contain an ExternalPub extension. This extension is generally useless for new group members, as its only purpose is to facilitate external joins.
 
 ### Deprecated
+
 - [#1801](https://github.com/openmls/openmls/pull/1801): Deprecated `MlsGroup::join_by_external_commit` in favor of `MlsGroup::external_commit_builder`.
 
 ## 0.7.0 (2025-07-17)
@@ -85,7 +92,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 - [#1641](https://github.com/openmls/openmls/pull/1641): Fixed missing storage of queued proposals & clearing of the queued proposals.
 
-## 0.6.0-pre.1 (2024-07-22)
+## 0.6.0 (2024-07-22)
 
 ### Added
 

CONTRIBUTING.md

@@ -47,14 +47,17 @@ Issue priorities are reflected with labels.
 
 ### Patches
 
-Sometimes, you have to work on another crate (e.g. [hpke-rs](https://crates.io/crates/hpke-rs)) alongside openmls. The 
-recommended way to proceed while developing locally is to patch openmls by adding the following to the root [Cargo.toml](./Cargo.toml): 
+Sometimes, you have to work on another crate (e.g. [hpke-rs](https://crates.io/crates/hpke-rs)) alongside openmls. The
+recommended way to proceed while developing locally is to patch openmls by adding the following to the root [Cargo.toml](./Cargo.toml):
+
 ```toml
 [patch.crates-io.hpke-rs]
 path = "../hpke-rs" # local path to the project
 ```
+
 Once you are done with your changes and feel it's ready to be submitted, you will have to make your patch point to a
 remote branch in order for the CI to succeed:
+
 ```toml
 [patch.crates-io.hpke-rs]
 git = "https://github.com/my-fork/hpke-rs"

Cargo.toml

@@ -21,14 +21,14 @@ resolver = "2"
 [workspace.dependencies]
 tls_codec = { version = "0.4.2", features = ["derive", "serde", "mls"] }
 
-openmls = { version = "0.7.0", path = "openmls" }
+openmls = { version = "0.7.1", path = "openmls" }
 
-openmls_traits = { version = "0.4.0", path = "traits" }
-openmls_test = { version = "0.2.0", path = "openmls_test" }
-openmls_basic_credential = { version = "0.4.0", path = "basic_credential" }
+openmls_traits = { version = "0.4.1", path = "traits" }
+openmls_test = { version = "0.2.1", path = "openmls_test" }
+openmls_basic_credential = { version = "0.4.1", path = "basic_credential" }
 
-openmls_rust_crypto = { version = "0.4.0", path = "openmls_rust_crypto" }
-openmls_libcrux_crypto = { version = "0.2.0", path = "libcrux_crypto" }
+openmls_rust_crypto = { version = "0.4.1", path = "openmls_rust_crypto" }
+openmls_libcrux_crypto = { version = "0.2.1", path = "libcrux_crypto" }
 
-openmls_memory_storage = { version = "0.4.0", path = "memory_storage" }
-openmls_sqlite_storage = { version = "0.1.0", path = "sqlite_storage" }
+openmls_memory_storage = { version = "0.4.1", path = "memory_storage" }
+openmls_sqlite_storage = { version = "0.1.1", path = "sqlite_storage" }

README.md

@@ -10,7 +10,8 @@
 [![Book][book-release-badge]][book-release-link]
 ![Rust Version][rustc-image]
 
-*OpenMLS* is a Rust implementation of the Messaging Layer Security (MLS) protocol, as specified in [RFC 9420](https://datatracker.ietf.org/doc/html/rfc9420).
+_OpenMLS_ is a Rust implementation of the Messaging Layer Security (MLS) protocol, as specified in [RFC 9420](https://datatracker.ietf.org/doc/html/rfc9420).
+
 <!-- The introduction of the book imports the lines up until here (line 13), excluding the headline and separately the lines below (starting from line 19, "Supported ciphersuite"). If the line numbers change here, please modify the imported lines in the book.-->
 
 It is a software library that can serve as a building block in applications that require end-to-end encryption of messages.
@@ -57,9 +58,11 @@ can bring their own implementation. See [traits](https://github.com/openmls/open
 details.
 
 ## Working on OpenMLS
+
 For more details when working on OpenMLS itself please see the [Developer.md].
 
 ## Maintenance & Support
+
 OpenMLS is maintained and developed by [Phoenix R&D] and [Cryspen].
 
 ## Acknowledgements
@@ -83,4 +86,3 @@ OpenMLS is maintained and developed by [Phoenix R&D] and [Cryspen].
 [Phoenix R&D]: https://phnx.im
 [Cryspen]: https://cryspen.com
 [Zulip]: https://zulip.com/
-

basic_credential/CHANGELOG.md

@@ -0,0 +1,8 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## 0.4.1 (2025-09-24)

basic_credential/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "openmls_basic_credential"
-version = "0.4.0"
+version = "0.4.1"
 authors = ["OpenMLS Authors"]
 edition = "2021"
 description = "A Basic Credential implementation for OpenMLS"

book/src/app_validation.md

@@ -10,15 +10,15 @@
 
 > The application using MLS is responsible for specifying which identifiers
 > it finds acceptable for each member in a group. In other words, following
-> the model that [[RFC6125]] describes for TLS, the application maintains a list
+> the model that [RFC6125][] describes for TLS, the application maintains a list
 > of "reference identifiers" for the members of a group, and the credentials
 > provide "presented identifiers". A member of a group is authenticated by first
 > validating that the member's credential legitimately represents some presented
 > identifiers, and then ensuring that the reference identifiers for the member
 > are authenticated by those presented identifiers
 >
 > -- [RFC9420, Section 5.3.1](https://www.rfc-editor.org/rfc/rfc9420.html#section-5.3.1-1)
->
+
 ### Validity of Updated Presented Identifiers
 
 > In cases where a member's credential is being replaced, such as the Update and
@@ -28,7 +28,7 @@
 >
 > -- [RFC9420, Section 5.3.1](https://www.rfc-editor.org/rfc/rfc9420.html#section-5.3.1-5)
 
-### Application ID is Not Authenticed by AS
+### Application ID is Not Authenticated by AS
 
 > However, applications MUST NOT rely on the data in an application_id extension
 > as if it were authenticated by the Authentication Service, and SHOULD gracefully
@@ -44,7 +44,7 @@
 > LeafNode, and reject any LeafNode where the total lifetime is longer than this
 > duration. In order to avoid disagreements about whether a LeafNode has a valid
 > lifetime, the clients in a group SHOULD maintain time synchronization (e.g.,
-> using the Network Time Protocol [[RFC5905]]).
+> using the Network Time Protocol [RFC5905][]).
 >
 > -- [RFC9420, Section 7.2](https://www.rfc-editor.org/rfc/rfc9420.html#section-7.2-10)
 
@@ -55,7 +55,7 @@
 > It is up to the application to decide what authenticated_data to provide and
 > how much padding to add to a given message (if any). The overall size of the
 > AAD and ciphertext MUST fit within the limits established for the group's AEAD
-> algorithm in [[CFRG-AEAD-LIMITS]].
+> algorithm in [CFRG-AEAD-LIMITS][].
 >
 > -- [RFC9420, Section 6.3.1](https://www.rfc-editor.org/rfc/rfc9420.html#section-6.3.1-11)