LibreKAT/Ocideck

Watch

Fork 0

[Feature] Publish a light-weight voluntary security attestation (COMPLIANCE.md) #549

New issue

Closed

opened 2026-07-22 13:42:57 +00:00 by brenno · 1 comment

brenno commented

2026-07-22 13:42:57 +00:00

Owner

The ORC WG (Eclipse Foundation) is drafting the framework for CRA Article 25 voluntary security attestations (VSAs) in orcwg/cra-attestations. Its light-weight template — proposals/template-lite.md, derived from BSI TR-03185-2 — is a checklist a project can fill in and publish as COMPLIANCE.MD next to LICENSE.md. This is the umbrella issue for doing that.

It fits our position exactly. assurance/CRA-2024-2847-positie.md settles that the regulation imposes nothing on us and that we follow it as a guideline anyway. A voluntary attestation is that same sentence in a form someone else can read: it takes on no obligation, and it answers the questions a downstream user would otherwise have to ask by e-mail.

Where we stand against the checklist, measured 2026-07-22:

	Requirement	State
GV.01–03	contribution guideline, quality standard, usage documentation	`CONTRIBUTING.md`, `docs/CHECKS.md`, `README.md` + `docs/USER_GUIDE.md`
LE.01–02	project and dependencies under an open source license	`LICENSE.md`, `docs/LICENSE_COMPLIANCE.md`
QA.01	direct dependencies listed, with checksums	`sbom/` (CycloneDX 1.6 + SPDX 2.3), `pubspec.lock`
QA.02	source and change history public	the forge
QA.03	how to file a vulnerability report	`SECURITY.md`
QA.04	repeatable test procedures	`docs/CHECKS.md`, `Makefile`
QA.05	memory-safety mitigations	open — see the separate issue
QA.06–07	more than one contributor, review by a non-author	cannot be ticked — see the separate issue
BR.01	build from source	`docs/BUILD.md`
BR.02–04	monotonic versions, integrity of released assets, release log	open — #520
VM.01	security contact	security@librekat.nl
VM.02	publish information about fixed vulnerabilities	partly: CHANGELOG and the tracker are public, there is no advisory form
EL.01	end-of-life communicated	open — see the separate issue

So most of it already exists and is simply not gathered anywhere.

What this issue delivers

COMPLIANCE.md in the repository root, filled in against the template, with a link per row to the thing that backs it.
The unticked boxes written out as such. A checklist with three honest "no"s is worth more than one with three quiet yesses; the template has room for an explanation and that is the point of it.
An explicit scope statement for dependencies. The proposal is emphatic here: an issuer should say which dependencies the attestation covers and which it does not. We bundle a JS layer and a native layer (opencv_core) that we do not maintain, so the honest answer is: this attestation covers OciDeck itself and no dependency.
Issuer, subject and date, unambiguous (AU.01–03): Stichting LibreKAT, the project URL, the version and the commit — SECURITY.md already notes that the version number alone does not pin down a commit, because nothing has been released.

Not in this issue. Signing, checksums, monotonic version identifiers and a dated release log (BR.02–04) belong to #520; the attestation will point there and say plainly that a release process does not exist yet. Whether Stichting LibreKAT is an open-source steward under Article 24 is a separate question with its own issue, and it determines what AU.01 may claim — so that one lands first.

Watch. orcwg/cra-attestations is a draft that changes; the template is at revision 0.1 and the heavy-weight variant is still empty. A weekly check on that repository has been scheduled outside this repository, and reports back when the template moves.

The ORC WG (Eclipse Foundation) is drafting the framework for CRA Article 25 voluntary security attestations (VSAs) in [orcwg/cra-attestations](https://github.com/orcwg/cra-attestations). Its light-weight template — `proposals/template-lite.md`, derived from [BSI TR-03185-2](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03185/BSI-TR-03185-2.html) — is a checklist a project can fill in and publish as `COMPLIANCE.MD` next to `LICENSE.md`. This is the umbrella issue for doing that. It fits our position exactly. [`assurance/CRA-2024-2847-positie.md`](assurance/CRA-2024-2847-positie.md) settles that the regulation imposes nothing on us and that we follow it as a guideline anyway. A *voluntary* attestation is that same sentence in a form someone else can read: it takes on no obligation, and it answers the questions a downstream user would otherwise have to ask by e-mail. **Where we stand against the checklist**, measured 2026-07-22: | | Requirement | State | |---|---|---| | GV.01–03 | contribution guideline, quality standard, usage documentation | `CONTRIBUTING.md`, `docs/CHECKS.md`, `README.md` + `docs/USER_GUIDE.md` | | LE.01–02 | project and dependencies under an open source license | `LICENSE.md`, `docs/LICENSE_COMPLIANCE.md` | | QA.01 | direct dependencies listed, with checksums | `sbom/` (CycloneDX 1.6 + SPDX 2.3), `pubspec.lock` | | QA.02 | source and change history public | the forge | | QA.03 | how to file a vulnerability report | `SECURITY.md` | | QA.04 | repeatable test procedures | `docs/CHECKS.md`, `Makefile` | | QA.05 | memory-safety mitigations | **open** — see the separate issue | | QA.06–07 | more than one contributor, review by a non-author | **cannot be ticked** — see the separate issue | | BR.01 | build from source | `docs/BUILD.md` | | BR.02–04 | monotonic versions, integrity of released assets, release log | **open** — #520 | | VM.01 | security contact | security@librekat.nl | | VM.02 | publish information about fixed vulnerabilities | partly: CHANGELOG and the tracker are public, there is no advisory form | | EL.01 | end-of-life communicated | **open** — see the separate issue | So most of it already exists and is simply not gathered anywhere. **What this issue delivers** - `COMPLIANCE.md` in the repository root, filled in against the template, with a link per row to the thing that backs it. - **The unticked boxes written out as such.** A checklist with three honest "no"s is worth more than one with three quiet yesses; the template has room for an explanation and that is the point of it. - **An explicit scope statement for dependencies.** The proposal is emphatic here: an issuer should say which dependencies the attestation covers and which it does not. We bundle a JS layer and a native layer (`opencv_core`) that we do not maintain, so the honest answer is: this attestation covers OciDeck itself and no dependency. - **Issuer, subject and date, unambiguous** (AU.01–03): Stichting LibreKAT, the project URL, the version *and* the commit — `SECURITY.md` already notes that the version number alone does not pin down a commit, because nothing has been released. **Not in this issue.** Signing, checksums, monotonic version identifiers and a dated release log (BR.02–04) belong to #520; the attestation will point there and say plainly that a release process does not exist yet. Whether Stichting LibreKAT is an *open-source steward* under Article 24 is a separate question with its own issue, and it determines what AU.01 may claim — so that one lands first. **Watch.** `orcwg/cra-attestations` is a draft that changes; the template is at revision 0.1 and the heavy-weight variant is still empty. A weekly check on that repository has been scheduled outside this repository, and reports back when the template moves.

brenno added the

triage

enhancement

labels

2026-07-22 13:42:57 +00:00

brenno referenced this issue

2026-07-22 13:43:17 +00:00

[Feature] Settle the steward question: is Stichting LibreKAT an open-source steward under Article 24? #550

brenno referenced this issue

2026-07-22 13:43:30 +00:00

[Feature] An end-of-life and support-period policy (EL.01) #551

brenno referenced this issue

2026-07-22 13:43:48 +00:00

[Feature] A channel someone can subscribe to for security notifications #552

brenno referenced this issue

2026-07-22 13:44:01 +00:00

[Feature] Document the memory-safety mitigations for the native layer (QA.05) #553

brenno referenced this issue

2026-07-22 13:44:19 +00:00

[Feature] State the bus factor and the review situation honestly (QA.06/QA.07) #554

brenno referenced this issue

2026-07-22 13:44:35 +00:00

[Feature] Machine-readable project metadata, so a third party can attest without asking #555

brenno referenced this issue from a commit

2026-07-22 15:40:44 +00:00

docs: publiceer de vrijwillige beveiligingsattestatie (COMPLIANCE.md)

brenno referenced this issue from a pull request that will close it,

2026-07-22 15:40:45 +00:00

docs: de CRA-attestatietros — rentmeester, EOL, feed, geheugenveiligheid, busfactor en COMPLIANCE.md #566

brenno closed this issue

2026-07-22 15:40:55 +00:00

brenno commented

2026-07-22 15:41:07 +00:00

Author

Owner

Done in #566. COMPLIANCE.md is in the repository root, filled in against template-lite.md, with a link per row.

Three rows are unticked and that is the point of the document: QA.06/QA.07 (one contributor, self-merge) and BR.02–04 (no releases). There is a "where this is weakest" section at the bottom, meant to be read before deciding to depend on the project.

Two claims were corrected while writing it, because they were not true. The response terms (5/10/90) live in tool/check_service_norms.dart and not in SECURITY.md; they are now stated as what we measure, explicitly not as a commitment to a reporter — a compliance document is not the place to quietly upgrade a promise. And the foundation's registered address is not invented: that field points at the foundation's own registration, and you probably want to fill it in yourself.

It has a gate, because this is the document that ages most quietly: compliance_attestation_test.dart checks that every reference resolves, that the security address matches SECURITY.md, and that QA.06/QA.07 do not get silently ticked. Planted and confirmed failing in all three directions.

Closing.

Done in #566. `COMPLIANCE.md` is in the repository root, filled in against `template-lite.md`, with a link per row. Three rows are unticked and that is the point of the document: QA.06/QA.07 (one contributor, self-merge) and BR.02–04 (no releases). There is a "where this is weakest" section at the bottom, meant to be read before deciding to depend on the project. Two claims were corrected while writing it, because they were not true. The response terms (5/10/90) live in `tool/check_service_norms.dart` and **not** in `SECURITY.md`; they are now stated as *what we measure*, explicitly not as a commitment to a reporter — a compliance document is not the place to quietly upgrade a promise. And the foundation's registered address is not invented: that field points at the foundation's own registration, and **you probably want to fill it in yourself**. It has a gate, because this is the document that ages most quietly: `compliance_attestation_test.dart` checks that every reference resolves, that the security address matches `SECURITY.md`, and that QA.06/QA.07 do not get silently ticked. Planted and confirmed failing in all three directions. Closing.