Rakomi

Wsparcie i cykl życia SDK

Rakomi publikuje datowane okna wsparcia dla każdej wersji głównej SDK — to kontrakt cyklu życia, który audytor może zacytować. Ta strona to widok dla ludzi naszej maszynowo czytelnej polityki wsparcia.

Wsparcie zgodne z CRA

🛡️ Polityka wsparcia zgodna z CRA

Datowany kontrakt wsparcia na wersję główną — co najmniej 5 lat (60 miesięcy) (CRA Art. 13(8)) oraz skoordynowane ujawnianie podatności (CRA Art. 14).

Uwaga: to postawa dokumentacyjna i polityczna, a nie ukończona ocena zgodności. Deklaracja zgodności UE oraz oznakowanie CE pojawiają się w dacie stosowania CRA (grudzień 2027) i nie zostały jeszcze wydane.

Polityka

Legenda statusów

Okna wsparcia

Polityka wygenerowana 2026-06-18

Poniższe daty są renderowane z kanonicznej, maszynowo czytelnej polityki pod adresem /.well-known/sdk-support.json — możesz zweryfikować, że ta strona nie jest wpisywana ręcznie.

Nie opublikowano jeszcze żadnej wersji GA.

Datowane okna wsparcia (co najmniej 5 lat / 60 miesięcy) pojawiają się w wersji 1.0. Paczki przed 1.0 (0.x) nie mają gwarancji stabilności ani wsparcia. Gdy pojawi się pierwsza wersja GA, jej datowane okno pojawi się tu automatycznie.

Wersja Status Wydano EOL Uwagi
Brak opublikowanych wersji — zobacz uwagę powyżej.

Proweniencja i SBOM

Po opublikowaniu każda paczka dostarczana jest z proweniencją kompilacji, którą możesz zweryfikować samodzielnie: 

npm audit signatures

Dostępne od pierwszego publicznego wydania — żadne podpisy jeszcze nie istnieją (przed publikacją).

Paczka npm SBOM (CycloneDX) Wydania Bezpieczeństwo
@rakomi/node npm sbom.cdx.json Wydania SECURITY.md
@rakomi/sdk-core npm generowane przy pierwszej publikacji Wydania SECURITY.md
@rakomi/react npm sbom.cdx.json Wydania SECURITY.md
@rakomi/react-native npm generowane przy pierwszej publikacji Wydania SECURITY.md

Odnośniki do Releases, SECURITY.md i SBOM staną się publicznie dostępne od pierwszego publicznego wydania — przed publikacją repozytorium źródłowe jest prywatne; te same pliki są też dołączane do każdego opublikowanego pakietu npm.

Zweryfikuj nas samodzielnie

Nie wierz nam na słowo. Od pierwszego publicznego wydania możesz potwierdzić każdą deklarację dotyczącą łańcucha dostaw na tej stronie spoza naszego CI — to dokładnie te polecenia, które uruchamia sceptyk:

  1. Verify registry signatures + provenance for the installed tree 
    npm audit signatures
  2. Verify the provenance attestation for a published version 
    gh attestation verify --repo rakomidev/rakomi-js "$(npm pack @rakomi/sdk-core@latest --silent)"
  3. Re-pack from this source at the immutable per-package tag and compare the SHA-512 digest 
    git checkout sdk-core/v<version> && npm ci && npm pack --workspace @rakomi/sdk-core

Pełny przewodnik: VERIFY.md — dostępny publicznie od pierwszego publicznego wydania.

Co proweniencja udowadnia — a czego nie

Each published package carries build provenance (SLSA Build L2) generated from this public repository via OpenID Connect trusted publishing — the bytes you install are cryptographically bound to the source you can read here.

It does not claim a bit-for-bit reproducible build against any private canonical source: shared internals are inlined at build time, and the readable source here is the real, inspectable source those bytes were produced from. The substantiated claim is provenance + signatures + a public npm pack you can re-run — not reproducibility against a hidden oracle.

How this repository works (per-release clean-room snapshots)

Each published version is a self-contained clean-room snapshot committed as a zero-parent (orphan) tree — there is deliberately no linear git ancestry between releases. The version history you should follow lives in the npm version timeline and the CHANGELOG, not in git parent links. Zero-parent commits here are the model working as designed, not a sign of tampering.

This public repository is a published artifact, not a development fork: pull requests are not merged into a per-release orphan tree. Development happens upstream; each release re-publishes a fresh snapshot. Report bugs, ask questions, or open a feature request through the channels listed in each package’s SECURITY.md, and report vulnerabilities privately via GitHub private vulnerability reporting (never in a public issue).

Security advisories (GHSA) describe a fix as "fixed in version 0.x.y — see the immutable per-package tag" rather than as a commit diff: under the orphan model the authoritative, verifiable reference is the published version and its signed, immutable tag, which provenance binds to the exact source you can read.

Więcej