[Serraniel]

Two related additions about what an organisation can actually rely on.

The support period: an honest absence

SECURITY.md left it to be inferred from "the supported version is the latest release." It now says it outright: no end-of-support date is promised, and none should be relied upon.

A date would be a number picked to look reassuring. A support commitment that is not kept is worse than an absent one — it is the difference between an organisation knowing it carries a risk and believing somebody else carries it.

What replaces the absent date is the part that is durable:

Published releases stay published	nothing is withdrawn to force an upgrade
Security fixes go to the newest release	disclosed as advisories once an update exists
The source cannot be taken away	AGPL-3.0-or-later, and the build is reproducible, so a fork can verify what it inherited
Abandonment will be announced	the repository gets archived and says so. It will not be left looking active

That last row is the one most projects skip, and it is the one an adopter most needs.

docs/compliance.md

Sendan is outside the CRA's scope — Art. 2(1) reaches products "made available on the market", Art. 3(22) defines that as supply in the course of a commercial activity, and Recital 18 says unmonetised FOSS is not such an activity. The maintainer is also not an Art. 3(14) steward, which requires a legal person supporting products intended for commercial activities.

The document exists anyway, because the evidence the Regulation asks a manufacturer to produce is worth producing either way, and because organisations that are in scope need to know what they can use.

The section that matters most

Who the manufacturer is. Upstream being out of scope does not move the obligation — it means nobody has discharged it. Anyone running Sendan commercially for other people, or shipping it inside a commercial offering, is the manufacturer of what they ship. This project cannot sign their declaration of conformity or carry their support period, and saying so prevents a false sense of compliance that silence would allow.

The Annex I mapping is honest, not a table of ticks

It records four places where Sendan does less than a literal reading would want, each with the reason:

• no in-product auto-update — a server that replaces its own code silently is a worse property when the client is the trust anchor
• no uploader authentication — the link is the credential; uploading is bounded by rate and retention limits rather than identity. An operator needing one puts it in the proxy
• deliberately reduced logging — a file identifier in a log defeats the deletion guarantee. An organisation needing per-object audit trails should learn about that tension before deploying, not after
• the released binaries carry no SBOM — the one real gap. The image does; The released binaries ship Go modules that no notices file records #313 covers the rest

It also notes that Recital 77 does not oblige a manufacturer to publish an SBOM at all — it is technical documentation shown on request. Sendan publishes one because an SBOM you cannot obtain is not evidence you can use.

Claims were checked, not written from memory

The CSP the demo actually serves is hash-based with no unsafe-inline, and object-src, form-action and frame-ancestors all 'none'; Referrer-Policy: no-referrer is what the link-fragment property rests on:

content-security-policy: default-src 'self'; script-src 'self' 'wasm-unsafe-eval' 'sha256-…';
  … object-src 'none'; base-uri 'none'; form-action 'none'; frame-ancestors 'none'
referrer-policy: no-referrer

Note

Adds one row to the README documentation table, in the same file #331 edits elsewhere. Whichever merges second may want a trivial rebase.

🤖 Generated with Claude Code