From 5ef90c904c7b0cd53e7e6bc351dfaea427e263bf Mon Sep 17 00:00:00 2001 From: tison Date: Mon, 9 Nov 2026 16:02:10 +0800 Subject: [PATCH 1/2] docs: define security reporting and library threat model --- README.md | 4 ++ SECURITY-THREAT-MODEL.md | 81 ++++++++++++++++++++++++++++++ SECURITY.md | 44 ++++++++++++++++ asyncband/SECURITY-THREAT-MODEL.md | 1 + asyncband/SECURITY.md | 1 + 5 files changed, 131 insertions(+) create mode 100644 SECURITY-THREAT-MODEL.md create mode 100644 SECURITY.md create mode 120000 asyncband/SECURITY-THREAT-MODEL.md create mode 120000 asyncband/SECURITY.md diff --git a/README.md b/README.md index a52abc42..4a7f3626 100644 --- a/README.md +++ b/README.md @@ -157,6 +157,10 @@ This crate is built against the latest stable release, and its minimum supported The policy is that the minimum Rust version required to use this crate can be increased in minor version updates. For example, if Asyncband 1.0 requires Rust 1.20.0, then Asyncband 1.0.z for all values of z will also require Rust 1.20.0 or newer. However, Asyncband 1.y for y > 0 may require a newer minimum version of Rust. +## Security + +Report suspected vulnerabilities privately to [security@apache.org](mailto:security@apache.org). See the [security policy](SECURITY.md) for reporting details and the [security threat model](SECURITY-THREAT-MODEL.md) for the library's security boundary and application responsibilities. + ## License and Trademarks This project is licensed under [Apache License, Version 2.0](LICENSE); the license file also records incorporated third-party works and their terms. diff --git a/SECURITY-THREAT-MODEL.md b/SECURITY-THREAT-MODEL.md new file mode 100644 index 00000000..153daa80 --- /dev/null +++ b/SECURITY-THREAT-MODEL.md @@ -0,0 +1,81 @@ + + +# Security Threat Model + +This model describes the security boundary of Apache Asyncband (Incubating), including its synchronization primitives, channels, initialization and work-coalescing utilities, object pools, and blocking adapter. Use it alongside the affected version's API documentation when assessing a report. The [security policy](SECURITY.md) defines the private reporting and disclosure process. + +## System and trust boundary + +Asyncband runs inside its caller's process. Its async APIs use standard Rust futures and wakers; they do not spawn tasks, own worker threads, or install runtime-specific timers or I/O drivers. The optional blocking adapter polls a future on the calling thread. Applications provide the executor, values, keys, callbacks, and resource-management policy. + +The assets Asyncband protects are the memory it manages or exposes, the ownership and synchronization of caller values, and the internal state needed to uphold each primitive's documented contract. Its library boundary includes inputs, concurrent operations, and cancellations reachable through public APIs. A remote user may influence these operations through an embedding application even though Asyncband itself has no network interface. + +The host application controls which tasks share a channel, lock, pool, or work-coalescing namespace. Asyncband does not authenticate users, authorize access to application data, or isolate untrusted executable code within the process. Callers must uphold Rust's unsafe preconditions and those of any unsafe APIs they use. Safe caller code cannot be assumed to preserve Asyncband's internal memory-safety invariants on its behalf. + +## Library responsibilities + +### Memory safety and ownership + +Safe use of Asyncband must not cause undefined behavior, including data races, use-after-free, double drops, or invalid references. This includes concurrent polling of different futures, cancellation by dropping a pending future, endpoint or guard destruction, and moving values between threads where the API permits it. `Send` and `Sync` implementations and mapped guards must enforce the required ownership, lifetime, and aliasing constraints. + +Safe Rust permits leaking a value with `mem::forget`; leaked guards can prevent progress, but must not make other safe operations memory-unsafe. Similarly, a caller panic or a logic error in a safe trait implementation must not become a memory-safety violation in Asyncband. Recovery and continued progress after a panic depend on the particular API contract. + +### Coordination and cancellation + +Locks must enforce their documented access rules. Channels must preserve their documented delivery and disconnection semantics. Permit accounting, initialization, and object checkout must remain consistent with each API's contract when operations race or are cancelled. Lost wakeups, incorrect cleanup, or incorrect sharing between independent primitive instances are library bugs and may have security impact in an embedding application. + +Cancellation is not application-level rollback. A dropped future does not undo side effects already performed by caller code, and work-coalescing APIs may retry initialization after cancellation or failure as documented. Applications must account for those semantics when performing external actions. + +## Application responsibilities and limits + +### Resource use and availability + +Applications choose capacities, bound request concurrency and payload sizes, and apply deadlines using their runtime. A bounded channel or pool limits the quantity documented by that API, not total process memory or CPU consumption. Pending sends can hold values outside a channel's buffer; received values and shared payloads can remain alive in application code. Unbounded channels, cached `OnceMap` entries, and concurrent work for distinct singleflight keys can grow with the workload. + +Progress also depends on the caller: tasks must be polled, guards and permits must be released, and receivers must drain or disconnect. A slow receiver can stall a lossless bounded broadcast channel. Cyclic lock dependencies, retained guards, or blocking an executor thread can deadlock an application. The blocking adapter's timeout cannot interrupt a call to `Future::poll` that does not return. + +These limits do not excuse a violation of a documented capacity or progress guarantee. For example, permanently losing permits after a supported cancellation sequence is a library defect, even when the application also needs its own admission control. + +### Shared data and caller code + +When results depend on caller identity or permissions, applications must include that context in `OnceMap` and singleflight keys, or use separate instances for different security domains. Equal keys deliberately share results within an instance. Object pools reuse application-managed objects; applications must validate and reset any tenant-specific or sensitive state before reuse. Asyncband does not erase secrets from released memory or redact arbitrary payloads exposed through their `Debug` implementations. + +Callbacks, initializers, trait implementations, and destructors execute as application code and may block, panic, or perform I/O. Reentrancy and panic recovery follow the individual API's documentation. Locks that do not poison cannot restore an application's partially modified data after a panic. Executor waker operations, including clone, wake, and drop, are expected not to panic; recovery from panicking wakers and arbitrary clone reentrancy are not general guarantees. These limits on recovery do not waive the memory-safety obligations above. + +## Assessing reports + +Distinguish a library defect from its security impact. A report should identify the affected API contract, how the behavior is reachable, and the consequences for an application. Potential memory-safety violations through safe APIs merit private assessment even without a demonstrated exploit. Availability failures can also be security issues when an attacker can trigger them across an application's trust boundary; they are not automatically excluded because Asyncband is a library. + +| Example | Assessment | +| ------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- | +| Cancelling a receive while a sender completes causes use-after-free. | A memory-safety defect requiring private security assessment. | +| Supported cancellation permanently loses permits and lets requests exhaust a service's capacity. | A coordination defect; assess attacker reachability and availability impact. | +| A receiver obtains a value sent to an unrelated channel instance. | A library isolation defect with potential confidentiality or integrity impact. | +| Distinct users share a result because the application supplies equal keys to one singleflight. | Application key and authorization design, unless Asyncband violates the documented key semantics. | +| An unbounded queue grows, or a bounded queue contains a few very large values. | Expected resource use requiring application limits, unless the library violates its documented accounting or cleanup rules. | +| A task retains a lock indefinitely or a caller callback never returns. | Application progress responsibility; the library provides no preemption of caller code. | + +The presence of `unsafe` code, a panic, or a dependency advisory alone does not establish exploitability. Maintainers assess the actual reachable behavior and affected versions with the Apache Security Team. Unclear impact is a reason to investigate privately, not a requirement for the reporter to develop an exploit. Ordinary correctness and performance bugs remain actionable through the public issue tracker. + +## Maintaining this model + +This model covers the library boundary. Suspected compromise of dependencies, release artifacts, or project infrastructure still warrants reporting through the appropriate [ASF security channel](https://www.apache.org/security/#reporting-a-vulnerability). + +Revisit the model when public APIs change ownership, sharing, cancellation, or resource guarantees; when new runtime, I/O, or FFI surfaces are introduced; or when a report exposes an unaddressed boundary. Evaluate older releases against their actual behavior and documented contracts; this document does not retroactively change those contracts. diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 00000000..a77e277e --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,44 @@ + + +# Security Policy + +Apache Asyncband (Incubating) is an in-process Rust concurrency library. The [security threat model](SECURITY-THREAT-MODEL.md) describes its security boundary and the responsibilities of applications that use it. + +## Reporting a vulnerability + +Report suspected vulnerabilities privately to [security@apache.org](mailto:security@apache.org), with "Asyncband" in the subject. Do not disclose an unpatched vulnerability in a public issue, pull request, GitHub Discussion, or the development mailing list. If you are unsure whether an issue has security impact, report it privately so maintainers can assess it with you. + +Send a plain-text report containing: + +- The affected Asyncband version or commit, enabled Cargo features, Rust version, target platform, and executor if relevant. +- A description and minimal reproducer, including the concurrent operations or cancellation sequence needed to trigger the issue. +- The observed result, expected behavior, and potential impact. Describe any attacker-controlled input or scheduling influence you have identified; a working exploit is not required to report a concern. + +For ordinary bugs and feature requests, use the [public issue tracker](https://github.com/apache/asyncband/issues). Follow the [ASF security reporting guidance](https://www.apache.org/security/#reporting-a-vulnerability) for vulnerabilities in ASF infrastructure or other Apache projects. + +## Handling reports + +The Asyncband PPMC is responsible for coordinating investigation and fixes with the reporter and the Apache Security Team. Reports sent to the ASF security address are routed to the project privately. The PPMC should identify a maintainer to coordinate each report and keep the Apache Security Team involved throughout the investigation. + +Maintainers follow the [ASF vulnerability handling process](https://www.apache.org/security/committers.html): acknowledge and assess the report privately, determine affected versions, coordinate a fix and any advisory or CVE with the Apache Security Team, and agree on disclosure with the reporter. Accepted vulnerabilities are disclosed with remediation guidance after, or together with, the release that addresses them. Reports classified as ordinary bugs should be moved to public discussion only after that assessment has been communicated to the reporter. + +## Versions and fixes + +Use the latest ASF-approved release. Reports concerning older releases or development code are also welcome; include whether the issue is reproducible on the latest release if you can check safely. Fixes are normally delivered in a new ASF-approved release. The PPMC evaluates backports case by case; this policy does not promise maintenance of every older release line or a fixed response or release deadline. Each advisory identifies the affected versions and available remediation. diff --git a/asyncband/SECURITY-THREAT-MODEL.md b/asyncband/SECURITY-THREAT-MODEL.md new file mode 120000 index 00000000..cef2ce67 --- /dev/null +++ b/asyncband/SECURITY-THREAT-MODEL.md @@ -0,0 +1 @@ +../SECURITY-THREAT-MODEL.md \ No newline at end of file diff --git a/asyncband/SECURITY.md b/asyncband/SECURITY.md new file mode 120000 index 00000000..9d571381 --- /dev/null +++ b/asyncband/SECURITY.md @@ -0,0 +1 @@ +../SECURITY.md \ No newline at end of file From d6a87ea937961feb3f2c467fa94ad0bfc3b07e1d Mon Sep 17 00:00:00 2001 From: tison Date: Mon, 9 Nov 2026 17:12:33 +0800 Subject: [PATCH 2/2] docs: consolidate security guidance at repository level --- README.md | 2 +- SECURITY-THREAT-MODEL.md | 8 +++++- SECURITY.md | 44 ------------------------------ asyncband/SECURITY-THREAT-MODEL.md | 1 - asyncband/SECURITY.md | 1 - 5 files changed, 8 insertions(+), 48 deletions(-) delete mode 100644 SECURITY.md delete mode 120000 asyncband/SECURITY-THREAT-MODEL.md delete mode 120000 asyncband/SECURITY.md diff --git a/README.md b/README.md index 4a7f3626..89ed1861 100644 --- a/README.md +++ b/README.md @@ -159,7 +159,7 @@ The policy is that the minimum Rust version required to use this crate can be in ## Security -Report suspected vulnerabilities privately to [security@apache.org](mailto:security@apache.org). See the [security policy](SECURITY.md) for reporting details and the [security threat model](SECURITY-THREAT-MODEL.md) for the library's security boundary and application responsibilities. +Report suspected vulnerabilities privately to [security@apache.org](mailto:security@apache.org), with "Asyncband" in the subject. Follow the [ASF vulnerability reporting process](https://security.apache.org/report/). ## License and Trademarks diff --git a/SECURITY-THREAT-MODEL.md b/SECURITY-THREAT-MODEL.md index 153daa80..7c7a996e 100644 --- a/SECURITY-THREAT-MODEL.md +++ b/SECURITY-THREAT-MODEL.md @@ -19,7 +19,13 @@ under the License. # Security Threat Model -This model describes the security boundary of Apache Asyncband (Incubating), including its synchronization primitives, channels, initialization and work-coalescing utilities, object pools, and blocking adapter. Use it alongside the affected version's API documentation when assessing a report. The [security policy](SECURITY.md) defines the private reporting and disclosure process. +This model describes the security boundary of Apache Asyncband (Incubating), including its synchronization primitives, channels, initialization and work-coalescing utilities, object pools, and blocking adapter. Use it alongside the affected version's API documentation when assessing a report. + +## Reporting a vulnerability + +Follow the [ASF vulnerability reporting process](https://security.apache.org/report/). Report suspected Asyncband vulnerabilities privately to [security@apache.org](mailto:security@apache.org), with "Asyncband" in the subject. Include the affected version, Cargo features, Rust version, target platform, executor if relevant, and a minimal reproducer describing the concurrent operations or cancellation sequence. Explain the observed behavior and potential impact; a working exploit is not required. + +Do not disclose a suspected vulnerability in a public issue, pull request, GitHub Discussion, or the development mailing list before private assessment. The Asyncband PPMC coordinates investigation and fixes with the reporter and the Apache Security Team under the [ASF vulnerability handling process](https://www.apache.org/security/committers.html). Ordinary bugs and feature requests belong in the [public issue tracker](https://github.com/apache/asyncband/issues). ## System and trust boundary diff --git a/SECURITY.md b/SECURITY.md deleted file mode 100644 index a77e277e..00000000 --- a/SECURITY.md +++ /dev/null @@ -1,44 +0,0 @@ - - -# Security Policy - -Apache Asyncband (Incubating) is an in-process Rust concurrency library. The [security threat model](SECURITY-THREAT-MODEL.md) describes its security boundary and the responsibilities of applications that use it. - -## Reporting a vulnerability - -Report suspected vulnerabilities privately to [security@apache.org](mailto:security@apache.org), with "Asyncband" in the subject. Do not disclose an unpatched vulnerability in a public issue, pull request, GitHub Discussion, or the development mailing list. If you are unsure whether an issue has security impact, report it privately so maintainers can assess it with you. - -Send a plain-text report containing: - -- The affected Asyncband version or commit, enabled Cargo features, Rust version, target platform, and executor if relevant. -- A description and minimal reproducer, including the concurrent operations or cancellation sequence needed to trigger the issue. -- The observed result, expected behavior, and potential impact. Describe any attacker-controlled input or scheduling influence you have identified; a working exploit is not required to report a concern. - -For ordinary bugs and feature requests, use the [public issue tracker](https://github.com/apache/asyncband/issues). Follow the [ASF security reporting guidance](https://www.apache.org/security/#reporting-a-vulnerability) for vulnerabilities in ASF infrastructure or other Apache projects. - -## Handling reports - -The Asyncband PPMC is responsible for coordinating investigation and fixes with the reporter and the Apache Security Team. Reports sent to the ASF security address are routed to the project privately. The PPMC should identify a maintainer to coordinate each report and keep the Apache Security Team involved throughout the investigation. - -Maintainers follow the [ASF vulnerability handling process](https://www.apache.org/security/committers.html): acknowledge and assess the report privately, determine affected versions, coordinate a fix and any advisory or CVE with the Apache Security Team, and agree on disclosure with the reporter. Accepted vulnerabilities are disclosed with remediation guidance after, or together with, the release that addresses them. Reports classified as ordinary bugs should be moved to public discussion only after that assessment has been communicated to the reporter. - -## Versions and fixes - -Use the latest ASF-approved release. Reports concerning older releases or development code are also welcome; include whether the issue is reproducible on the latest release if you can check safely. Fixes are normally delivered in a new ASF-approved release. The PPMC evaluates backports case by case; this policy does not promise maintenance of every older release line or a fixed response or release deadline. Each advisory identifies the affected versions and available remediation. diff --git a/asyncband/SECURITY-THREAT-MODEL.md b/asyncband/SECURITY-THREAT-MODEL.md deleted file mode 120000 index cef2ce67..00000000 --- a/asyncband/SECURITY-THREAT-MODEL.md +++ /dev/null @@ -1 +0,0 @@ -../SECURITY-THREAT-MODEL.md \ No newline at end of file diff --git a/asyncband/SECURITY.md b/asyncband/SECURITY.md deleted file mode 120000 index 9d571381..00000000 --- a/asyncband/SECURITY.md +++ /dev/null @@ -1 +0,0 @@ -../SECURITY.md \ No newline at end of file