RFC-0002 — EU Cyber Resilience Act (CRA) readiness posture

1. Summary

This RFC documents the xiboplayer project's public posture on EU Regulation 2024/2847 — the Cyber Resilience Act (CRA) — as of 2026-04-16, ahead of the regulation's main obligations taking effect on 2027-12-11 and the manufacturer reporting obligations on 2026-09-11. The public xiboplayer binaries and source are distributed AS-IS under AGPL-3.0-or-later and rely on the free-and-open-source-software carve-out codified in Article 2(5) and Recital 18 of the Regulation. We ship this RFC publicly, dated, and signed so that customers, redistributors, and market-surveillance authorities have a written record of what we claim, what we decline, and what we have actually built on the ground by today.

2. Scope

2.1 In scope of this RFC

Every artefact the xiboplayer project publishes or distributes from an xiboplayer.org / xibo-players.github.io surface, including:

• Source code on github.com/xibo-players/* under AGPL-3.0-or-later
• Binary releases on dl.xiboplayer.org (RPM, DEB repos), GitHub Releases, and pre-built kiosk images on images.xiboplayer.org
• Hosted documentation on xiboplayer.org
• Every repo's SECURITY.md and the canonical /.well-known/security.txt

2.2 Out of scope of this RFC

• The Xibo CMS itself — upstream project run by Xibo Signage Ltd; they speak for their own CRA posture
• Downstream integrators — anyone shipping xiboplayer inside a commercial product (integrator appliances, OEM signage packages, paid hosted services) becomes their own CRA "manufacturer" for their product; this RFC does not transfer that obligation to upstream
• Third-party dependencies (Electron, Chromium, Node, Android runtime, Tizen WRT, webOS runtime) — those are their vendors' problem and show up in our SBOM for traceability only

2.3 Maintainer status

The public project is maintainer-led, single-developer-primary (Pau Aliagas, Catalonia, European Union) with community contributions via GitHub. There is no legal entity that "places the binaries on the market" in the commercial sense — a fact material to §5.

3. What we do today (2026-04-16)

All items below are live, in-tree, and verifiable. This is a statement of fact, not a statement of future commitment.

3.1 Coordinated disclosure channel

• security@xiboplayer.org — monitored inbox; forwards to the maintainer
• PGP key for encrypted reports: 991E 74C3 A033 673F 4FCF 25B8 B7D2 5A81 02F6 3D6A (UID xiboplayer Security <security@xiboplayer.org>), published on keys.openpgp.org and keyserver.ubuntu.com since 2026-04-14
• SECURITY.md present in the SDK repo and propagating to all player-repo templates
• /.well-known/security.txt per RFC 9116
• GitHub Security Advisories enabled on all xibo-players/* repos; private-advisory workflow available to researchers who prefer GitHub over email

3.2 Software Bill of Materials (SBOM)

• CycloneDX JSON 1.5+ produced and attached to every release of the xiboplayer SDK as of v0.7.x, via .github/workflows/publish.yml using anchore/sbom-action@v0.
• We ship SBOMs for downstream transparency, not as a compliance attestation — see §5.3.

3.3 Signed commits and signed releases

• Release tags on xibo-players/xiboplayer from v0.7.0 onward are GPG-signed. A deep-sign audit on 2026-04-10 covered the full v0.7.0~1..HEAD range (509 commits, 18 tags); 96% signed cleanly at that checkpoint. The v0.7.0..HEAD range as of 2026-04-16 maintains 100% signing coverage.
• RPM and DEB packages published to dl.xiboplayer.org are signed with packages@xiboplayer.org (04A9 1796 92E8 6CF1 1D10 3CBF 5A30 EA2B B69D 32F2), live since 2026-03-30
• ISO images on images.xiboplayer.org are signed with images@xiboplayer.org (0B21 BFF6 6C83 EB4B 0E05 CF54 5F90 8630 B780 45FF), CI integration pending per the Code-signing policy

3.4 Vulnerability management in CI

• Dependabot enabled across all xibo-players/* repos for the dependency ecosystems in use (npm, pnpm, GitHub Actions, Cargo, gems)
• CodeQL runs on SDK PRs and weekly on main
• anchore/scan-action / grype runs against every built SBOM with severity-cutoff: critical, fail-build: true — a CRITICAL-severity CVE in a direct dependency blocks the release pipeline

3.5 Transparency artefacts already live

• Privacy policy — effective 2026-04-15. States plainly: the player software has no telemetry, no phone-home, no maintainer-side data collection
• Code-signing policy — documents every signing authority, the approval chain, and an independent-verification recipe

4. What we do not do yet (honest gaps)

We are deliberately explicit about what today's posture does not include, so downstream consumers do not infer obligations we have not assumed.

5. Legal interpretation (our read, not legal counsel)

This section is a good-faith interpretation of the regulation as published in the Official Journal on 2024-11-20 (https://eur-lex.europa.eu/eli/reg/2024/2847/oj). None of it is legal advice and it will be revised when authoritative guidance contradicts or refines it.

5.1 Why we lean on the OSS carve-out

Article 2(5), read with Recital 18, exempts from the Regulation's scope free and open-source software that is not placed on the market in the course of a commercial activity.

Our posture leans on three facts:

1. The public binaries are free. There is no paid tier, paid support, paid SaaS, paid feature flag, commercial dual-license, or promotional funnel to a paid product on the OSS-branded surfaces.
2. No regular-and-continuous revenue stream linked to the binaries. The guidance in Recital 18 about "not characterised by a commercial activity" specifically calls out absence of revenue. Infrastructure is currently donated in-kind (Cloudflare R2 free tier, GitHub free public repos, self-hosted build host).
3. The distribution surface is project-focused. The xiboplayer.org domain, dl.xiboplayer.org package repos, and github.com/xibo-players/* sources exist to serve the open-source project itself, not to funnel users toward a paid product.

5.2 Why our SBOMs are not a compliance claim

CRA Annex I §2(1) requires manufacturers to "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials". Because we do not claim manufacturer status, our SBOMs are not filed under this obligation; they are published under an OSS-hygiene rationale so that downstream commercial integrators can satisfy their own Annex I §2(1) obligation without duplicating our work.

5.3 Why we do not publish a response-time SLA

A published SLA — even one as narrow as "72 h acknowledgement / 30 d fix" — creates an enforceable commitment that a market-surveillance authority can read as evidence of manufacturer-like behaviour, which in turn weakens the Article 2(5) defence. RFC-0001 §3.3 explicitly refuses such language on the OSS surface for this reason. This is a material departure from the most common "mature OSS project" template (which tends to publish 72 h / 90 d numbers). We believe the departure is the right call under current EU law and will revisit if authoritative guidance (ENISA implementing act; Commission delegated act) contradicts it.

6. Commitments

These are the hard commitments we make under this RFC. Each has an owner, a date, and a verifiable artefact. Missing a committed date triggers a written amendment within 30 days stating the slip and the new date.

7. First-mover signal

We publish this RFC on 2026-04-16 — 19 months before the main CRA applicability date of 2027-12-11, and five months before the Art. 14 manufacturer reporting obligations kick in on 2026-09-11. We do so knowing that:

• The FOSS scope in Article 2(5) and Recital 18 will likely be refined by delegated acts whose text is not yet public
• ENISA implementing guidance on the reporting platform is still in consultation as of 2026-04-16 (Commission CRA landing page)
• The vast majority of small-to-medium OSS signage projects in the EU space have published nothing comparable on 2026-04-16. Shipping a dated, signed posture document ahead of that curve is itself the point: we would rather be visible, dated, and corrigible than silent and deniable

If authoritative EU guidance published after 2026-04-16 contradicts any interpretation in §5, we commit (see C-4) to amending this RFC within 30 days of the contradicting authority's publication, with a full changelog entry — and, if the amendment materially changes downstream obligations, a blog post flagging the change.

This is not a claim of compliance. It is a claim of good-faith transparency at a date.

8. References

• EU Regulation 2024/2847 (Cyber Resilience Act), OJ L 2024/2847, 20 November 2024
• European Commission — Cyber Resilience Act policy page
• ENISA — Cyber Resilience Act publications
• ISO/IEC 29147:2018 — Vulnerability disclosure
• ISO/IEC 30111:2019 — Vulnerability handling processes
• RFC 9116 — A File Format to Aid in Security Vulnerability Disclosure
• AGPL-3.0 licence text
• Apache Software Foundation — CRA position, 2024
• Linux Foundation Europe — CRA resource centre
• Internal: RFC-0001 — OSS AS-IS posture, Security page, Code-signing policy, Privacy policy

9. Changelog

• 2026-04-16 — Initial publication (Pau Aliagas).

RFC-0002 is authored by Pau Aliagas pau@xiboplayer.org on behalf of the xiboplayer open-source project, in Catalonia, European Union. It is not legal advice.