Der Katalog lebt in einem einzigen Registry (src/lib/tools.ts), das die Navbar und das Home-Grid steuert.

Rund um die Tools selbst:

• Fügen Sie alles auf der Startseite ein. Das Artefakt wird anhand seiner Bytes erkannt (PEM-Label oder DER-Header, siehe src/lib/pki/detect.ts) und öffnet sich im Tool, das es liest.
• Ein Artefakt im falschen Tool sagt das und bietet das richtige an, wobei sein Inhalt übernommen wird. Die Übergabe erfolgt im Speicher, niemals über die URL, sodass sie aus History-Dateien, Proxy-Logs und Bookmark-Syncs herausbleibt.
• "Same artefact in" unter einem Ergebnis trägt es zu den anderen Tools, die es lesen, sodass ein Einfügen mehrere Fragen beantwortet.
• Ein Verdict-Band beantwortet die Frage, für die das Tool existiert, vor jeder Detailzeile, und die Werte, die in einem Ticket zitiert werden, sind mit einem Klick kopierbar.
• Jedes Tool nimmt ein eingefügtes Artefakt oder eine hochgeladene Datei entgegen und liefert eine Beispieleingabe, damit Sie es ohne eine ausprobieren können. / setzt den Cursor in die Eingabe.

Überprüfbare Privatsphäre

Die Behauptung "es verlässt niemals Ihren Browser" ist von innerhalb der Seite überprüfbar:

• Jedes Eingabefeld trägt ein Verify-Panel, das die eigene connect-src-Direktive der Seite aus der Richtlinie ausliest, mit der sie ausgeliefert wurde, die Anfragen zählt, die seit Ihrem Einfügen Daten nach außen tragen könnten, und einen Live-Versuch ausführt, den der Browser vor Ihnen verweigert, wobei die Direktive zitiert wird, die ihn blockiert hat.
• Ein eingefügter privater Schlüssel wird benannt und verhüllt: das Feld sagt, was es enthält und dass es die Seite nicht verlassen hat, mit Clear it und Show it anyway. Nichts wird dekodiert, übertragen oder gespeichert.
• Öffnen Sie den Netzwerk-Tab Ihres Browsers, während Sie ein Zertifikat dekodieren: Sie werden keine einzige Anfrage sehen.

Ausführen

Führen Sie immer ein gepinntes, unveränderliches Release-Tag (vX.Y.Z) aus, niemals latest: ein bewegliches Tag kann nicht auditiert oder zurückgerollt werden. Für die stärkste Garantie pinnen Sie den Image-Digest (...@sha256:...).

Öffnen Sie dann http://localhost:8080.

Öffentliche Images

Jedes Release wird unter demselben unveränderlichen vX.Y.Z-Tag veröffentlicht bei:

Selbst hosten mit Docker Compose

Das Repository liefert eine vollständig gehärtete docker-compose.yml (schreibgeschütztes Root-Dateisystem, entfernte Capabilities, Speicher- und CPU-Limits); verwenden Sie diese Datei direkt statt dieses minimale Beispiel.

Das Image wird aus nginx:alpine-slim gebaut, wiegt etwa 25 MB, lauscht auf dem nicht-privilegierten Port 8080 und läuft als Non-Root-Benutzer.

Lokale Entwicklung

Erfordert Node 24 (die Version, mit der das Image und CI bauen) und pnpm 11. Die exakte pnpm-Version ist durch das packageManager-Feld von package.json gepinnt, sodass corepack enable ausreicht, um sie zu erhalten.

Das Docker-Image bauen

Wie es funktioniert

• SvelteKit 2 + TypeScript, gebaut mit adapter-static zu reinem HTML/JS: jede Route ist vorgerendert und es gibt keine Node-Runtime in der Produktion.
• TailwindCSS für das Styling, auf dem youkyi-Designsystem: standardmäßig hell, dunkel als Signatur-Theme (die Wahl wird persistiert).
• Das gesamte Parsing lebt in reinen, testbaren Funktionen unter src/lib/pki/, ohne Svelte-Import: parse.ts, chain.ts, crl.ts, pkcs7.ts, pkcs12.ts, asn1.ts, convert.ts, format.ts, pem.ts, oids.ts, detect.ts, generate.ts und sign.ts. Jede Route unter src/routes/ ist eine dünne UI-Hülle um sie herum.
• @peculiar/x509 v2 baut seine Objekte über tsyringe auf, was auf der Konsumentenseite einen Reflect-Metadata-Polyfill benötigt, daher wird @abraham/reflection in jedem Modul, das die Bibliothek verwendet, vor ihr importiert.
• PKCS#7 und PKCS#12 laufen über pkijs, dessen Web-Crypto-Engine einmalig in src/lib/pki/engine.ts registriert wird.
• Unit-Tests liegen in tests/pki/ (Vitest) und Browser-Tests in e2e/ (Playwright). Fixtures sind echte öffentliche Roots (ISRG Root X1/X2) plus eine generierte EC-Kette und CSR, siehe scripts/generate-fixtures.mjs.

Sicherheitslage

• Kein Netzwerk-Egress aus der App. Die Content-Security-Policy wird von SvelteKit als <meta>-Tag mit connect-src 'none' ausgegeben; nginx fügt frame-ancestors 'none', X-Frame-Options, X-Content-Type-Options, Referrer-Policy: no-referrer, eine restriktive Permissions-Policy und die Cross-Origin-Isolation-Header hinzu. Die Vercel-Demo sendet denselben Header-Satz (siehe vercel.json).
• Limits für feindliche Eingaben. Jeder Decoder lehnt eine Eingabe über 4 MB ab, und der ASN.1-Walker ist in Knotenanzahl und Verschachtelungstiefe begrenzt, sodass ein fehlerhaftes Artefakt den Tab nicht hängen lassen kann.
• Gehärtete Runtime. nginx läuft als Non-Root-Benutzer auf Port 8080; die mitgelieferte docker-compose.yml fügt ein schreibgeschütztes Root-Dateisystem, cap_drop: ALL, no-new-privileges und Ressourcenlimits hinzu.
• Supply Chain. Beide Basis-Images sind auf unveränderliche Digests gepinnt, die von Renovate aktuell gehalten werden. CI schlägt bei einem behebbaren HIGH/CRITICAL-Befund fehl, sowohl im Repository (trivy fs) als auch beim frisch gebauten Image, das zudem abgelehnt wird, wenn sein Basis-OS end-of-life ist, sodass ein verwundbares Image niemals gepusht wird. Lizenzen werden in einem separaten, nicht blockierenden Durchlauf gescannt.
• Barrierefreiheit. Die Oberfläche erfüllt WCAG 2.2 AA.

Versionierung & Releases

Dieses Projekt folgt Semantic Versioning und Conventional Commits. Bemerkenswerte Änderungen werden in CHANGELOG.md festgehalten. Beitragsregeln stehen in CONTRIBUTING.md.

Ein Release erstellen

1. Benennen Sie in CHANGELOG.md die Überschrift ## [Unreleased] in die neue Version mit dem heutigen Datum um, z. B. ## [1.2.3] - 2026-06-01, fügen Sie eine frische leere ## [Unreleased] darüber hinzu und aktualisieren Sie die Link-Referenzen am Ende der Datei.
2. Erhöhen Sie "version" in package.json auf dieselbe Nummer.
3. Committen Sie auf main (ein konventioneller Commit, z. B. chore(release): 1.2.3) und pushen Sie.
4. Taggen Sie den Commit und pushen Sie das Tag:
   root@kitploit:~

   git tag -a v1.2.3 -m "pki-toolbox v1.2.3"
   git push origin v1.2.3
   

Die Pipeline

Lint, Unit-Tests und End-to-End-Tests laufen bei jedem Push. Die Scan-, Build- und Release-Stufen stammen aus den gemeinsamen YouKyi-Infra/ci-infrastructure/ci-catalog-Komponenten (trivy-scan, docker-build, gitlab-release), gepinnt per Version in .gitlab-ci.yml.

Ein vX.Y.Z-Tag durchläuft die gesamte Kette: Scan, Image-Build, Image-Scan, Push von vX.Y.Z zur GitLab-Registry und zu den öffentlichen Mirrors (ghcr.io, Docker Hub), dann ein GitLab Release, dessen Notes der passende ## [X.Y.Z]-Abschnitt aus CHANGELOG.md sind (ein leerer Abschnitt lässt den Job fehlschlagen, statt leere Notes zu veröffentlichen).

Ein Push auf main durchläuft dieselbe Pipeline ohne den Release-Schritt, und der Image-Job läuft nur, wenn sich eine Datei geändert hat, die den Build beeinflusst, sodass ein reiner Docs- oder Config-Push das Image nicht neu baut.

Abhängigkeiten werden von Renovate aktuell gehalten, das das gemeinsame Renovate-Bot/renovate-config-Preset erweitert (siehe renovate.json).

Lizenz

MIT