Security fixes are released on top of the latest published minor line. Older 0.x lines do not receive backports — upgrade to the latest release to stay patched. (This table is updated as part of every release; the release workflow checks that it covers the version being tagged.)

Exactly as long as it is the latest minor line. The day a new minor release (0.15.0) is published, the previous line (0.14.x) stops receiving fixes, security fixes included; there is no overlap window and no long-term-support line. A fix for a vulnerability ships as a patch release of the current line — 0.14.1 for GHSA-hr9h-6jvf-wvg6 is the precedent. Pin and plan accordingly: if you need a longer support period than that, you need to carry it yourself (see the next section).

This is the policy as it stands at 0.x; STABILITY.md says what changes at 1.0.

This section is for anyone who places on the EU market a product with digital elements that contains these crates. It is a description of what this project provides, not legal advice.

The project's own position, as the maintainer reads it. These crates are free and open-source software published by an individual and not monetised: no paid support, no charge for the crates. Recital 18 of Regulation (EU) 2024/2847 treats such software as not made available in the course of a commercial activity, and an open-source software steward (Article 24) is a legal person, which an individual maintainer is not. If that changes — paid support, or hosting by a foundation — this section changes with it.

Your obligations reach these crates. Article 13(5) requires you to "exercise due diligence when integrating components sourced from third parties", free and open-source software included; Annex I, Part II(1) requires an SBOM covering at least your top-level dependencies; and Article 13(6) requires you, on identifying a vulnerability in a component, to report it to whoever maintains that component. Article 14's reporting obligations apply from 11 September 2026 (Article 71(2)). What this project gives you for each of those:

Your legal deadlines win over our embargo. The coordinated-disclosure timeline below is a default for reporters with no other obligation. If the law requires you to notify a CSIRT or ENISA about an actively exploited vulnerability in a product that contains these crates, do so on the law's timetable, and tell us at the same time; nothing in this policy asks you to delay a notification you are required to make.

This policy covers every crate published from this repository:

• The four workspace crates — a2a-protocol-types, a2a-protocol-client, a2a-protocol-server and a2a-protocol-sdk. These are the members of the root Cargo.toml that are published; the example, benchmark, book-test and TCK members are publish = false and are not covered.
• bindings/a2a-protocol-slimrpc, which is publishable and is covered by this policy, even though it is deliberately outside the root workspace — it is not in Cargo.toml's members list and carries its own Cargo.lock and its own deny.toml, because agntcy-slim-rpc brings 359 transitive dependencies into a tree the SDK crates must not inherit. "All crates in the workspace" therefore did not reach it, which is why this section now names it. Two things a reporter should know about it: it has never been published to crates.io (see RELEASING.md), so no released artifact is affected today; and it carries no advisory waiver since 2026-10-15. Its move to agntcy-slim-rpc 3.4.1 took rustls to 0.23.46 (the aws-lc-rs pin under slim-auth that held it at 0.23.43 is =1.18.1 in mls-rs-crypto-awslc 0.25.1) and removed unsafe-libyaml, so the five waivers it carried until then (RUSTSEC-2026-0285, -0346, -0348, -0349 and RUSTSEC-2024-0449) are gone from its deny.toml and osv-scanner.toml; their notes there say how each was cleared. A report about anything in the binding is in scope and welcome.

If you discover a security vulnerability in this project, please report it responsibly. Do not open a public GitHub issue.

1. GitHub Security Advisories (preferred): Open a draft advisory at https://github.com/tomtom215/a2a-rust/security/advisories/new. The report stays private to you and the maintainers, and the channel is encrypted in transit by GitHub.
2. Email: Send a detailed report to tomf@tomtomtech.net — the address in this project's copyright headers.

security@a2a-rust.dev does not work. Earlier revisions of this file listed it as the primary channel, but a2a-rust.dev is not registered (NXDOMAIN), so mail to it is undeliverable and a report sent there would have been silently lost. Use one of the two channels above. The dedicated address will be restored here once the domain is live.

Not available. There is no published PGP key for this project, so reports sent by email cannot be encrypted end-to-end. This is a real gap for anyone who needs to disclose an unpatched vulnerability over untrusted mail.

Until a key is published, prefer GitHub Security Advisories (channel 1), which keeps the report private without needing one. If you must use email and the contents are sensitive, send a short notice without details and ask for an encrypted channel first.

Know what you can and cannot verify about a release:

If you need a cryptographic link between a published version and this repository, use the build provenance attestations described in PROVENANCE.md. Annotation was adopted at v0.8.0 and is enforced. Signing is enforced from the first release after v0.14.1: the trusted keys are the files in .github/release-signers/, which is also how an adopter obtains them.

• Description of the vulnerability and its potential impact.
• Steps to reproduce or a minimal proof of concept.
• Affected crate(s) and version(s).
• Any suggested fix, if available.

Your lockfile, not this repository's, decides which version of a dependency you build. When a dependency of these crates publishes a security fix, cargo moves you to it only if you update that dependency, or if a new release of these crates raises its minimum to the fixed version. Updating an a2a crate alone does neither when the old version still satisfies the requirement — an adopter found exactly that with rustls and RUSTSEC-2026-0285 on 0.12.1.

From 0.14.0 on, no requirement in a published manifest admits a version with a RustSec advisory: scripts/check_advisory_floors.py, a CI gate, tests every published version each normal and build dependency admits against the RustSec database. So upgrading these crates moves you off every advisory, known when the release was cut, in the crates they depend on directly. It says nothing about those crates' own dependencies, which their requirements govern; for those, and for advisories published since, update the dependency yourself (cargo update -p rustls) and run cargo audit or cargo deny check advisories against your own lockfile.

We follow a 90-day coordinated disclosure timeline:

1. Day 0 -- Report received; we acknowledge within 3 business days.
2. Day 1-14 -- We triage the issue, confirm validity, and assess severity.
3. Day 15-90 -- We develop and test a fix, coordinating with the reporter.
4. Day 90 -- Public disclosure, with a CVE identifier if applicable.

If a fix requires more time, we will negotiate an extension with the reporter. We aim to release a patch as quickly as possible, ideally well before the 90-day deadline.

We gratefully credit reporters in release notes and security advisories (unless anonymity is requested).