Il catalogo vive in un unico registry (src/lib/tools.ts) che guida la navbar e la griglia della home.

Attorno agli strumenti stessi:

• Incolla qualsiasi cosa nella home page. L'artefatto viene riconosciuto dai suoi byte (etichetta PEM o header DER, vedi src/lib/pki/detect.ts) e si apre nello strumento che lo legge.
• Un artefatto nello strumento sbagliato lo segnala e propone quello corretto, trasferendone il contenuto. Il passaggio avviene in memoria, mai tramite URL, così resta fuori da file di cronologia, log dei proxy e sincronizzazioni dei bookmark.
• "Stesso artefatto in" sotto un risultato lo porta agli altri strumenti che lo leggono, così un solo incolla risponde a più domande.
• Una banda di verdetto risponde alla domanda per cui lo strumento esiste prima di qualsiasi riga di dettaglio, e i valori che finiscono citati in un ticket si copiano con un click.
• Ogni strumento accetta un artefatto incollato o un file caricato, e include un input di esempio per provarlo senza averne uno. / posiziona il cursore nell'input.

Privacy verificabile

L'affermazione "non lascia mai il tuo browser" è verificabile dall'interno della pagina:

• Ogni casella di input include un pannello Verify che rilegge la direttiva connect-src della pagina dalla policy con cui è stata servita, conta le richieste in grado di trasportare dati all'esterno da quando hai incollato, ed esegue un tentativo live che il browser rifiuta davanti a te, citando la direttiva che lo ha bloccato.
• Una chiave privata incollata viene nominata e velata: la casella dice cosa contiene e che non ha lasciato la pagina, con Clear it e Show it anyway. Nulla viene decodificato, trasmesso o memorizzato.
• Apri la scheda network del tuo browser mentre decodifichi un certificato: non vedrai una singola richiesta.

Eseguirlo

Esegui sempre un tag di release fissato e immutabile (vX.Y.Z), mai latest: un tag mobile non può essere verificato né ripristinato. Per la garanzia più forte, fissa il digest dell'immagine (...@sha256:...).

Poi apri http://localhost:8080.

Immagini pubbliche

Ogni release è pubblicata, sotto lo stesso tag immutabile vX.Y.Z, su:

Self-host con Docker Compose

Il repository include un docker-compose.yml completamente rafforzato (filesystem root in sola lettura, capability rimosse, limiti di memoria e CPU); usa direttamente quel file invece di questo esempio minimale.

L'immagine è costruita da nginx:alpine-slim, pesa circa 25 MB, ascolta sulla porta non privilegiata 8080 e gira come utente non-root.

Sviluppo locale

Richiede Node 24 (la versione con cui l'immagine e la CI compilano) e pnpm 11. La versione esatta di pnpm è fissata dal campo packageManager di package.json, quindi corepack enable è sufficiente per ottenerla.

Costruire l'immagine Docker

Come funziona

• SvelteKit 2 + TypeScript, compilato con adapter-static in puro HTML/JS: ogni route è prerenderizzata e non c'è runtime Node in produzione.
• TailwindCSS per lo styling, sul design system youkyi: light di default, dark come tema distintivo (la scelta è persistita).
• Tutto il parsing vive in funzioni pure e testabili sotto src/lib/pki/, senza import Svelte: parse.ts, chain.ts, crl.ts, pkcs7.ts, pkcs12.ts, asn1.ts, convert.ts, format.ts, pem.ts, oids.ts, detect.ts, generate.ts e sign.ts. Ogni route sotto src/routes/ è un sottile shell UI attorno a esse.
• @peculiar/x509 v2 costruisce i suoi oggetti tramite tsyringe, che richiede un polyfill dei metadata Reflect lato consumer, quindi @abraham/reflection viene importato prima di esso in ogni modulo che usa la libreria.
• PKCS#7 e PKCS#12 passano attraverso pkijs, il cui engine Web Crypto è registrato una volta in src/lib/pki/engine.ts.
• Gli unit test vivono in tests/pki/ (Vitest) e i test browser in e2e/ (Playwright). Le fixture sono root pubbliche reali (ISRG Root X1/X2) più una catena EC e una CSR generate, vedi scripts/generate-fixtures.mjs.

Postura di sicurezza

• Nessuna uscita di rete dall'app. La Content-Security-Policy è emessa da SvelteKit come tag <meta> con connect-src 'none'; nginx aggiunge frame-ancestors 'none', X-Frame-Options, X-Content-Type-Options, Referrer-Policy: no-referrer, una Permissions-Policy restrittiva e gli header di isolamento cross-origin. La demo Vercel invia lo stesso set di header (vedi vercel.json).
• Limiti su input ostili. Ogni decoder rifiuta un input superiore a 4 MB, e il walker ASN.1 è limitato in numero di nodi e profondità di annidamento, così un artefatto malformato non può bloccare la scheda.
• Runtime rafforzato. nginx gira come utente non-root sulla porta 8080; il docker-compose.yml incluso aggiunge un filesystem root in sola lettura, cap_drop: ALL, no-new-privileges e limiti di risorse.
• Supply chain. Entrambe le immagini base sono fissate a digest immutabili mantenuti aggiornati da Renovate. La CI fallisce su un finding HIGH/CRITICAL correggibile, sia sul repository (trivy fs) sia sull'immagine appena costruita, che viene anche rifiutata quando il suo OS base è end-of-life, così un'immagine vulnerabile non viene mai pubblicata. Le licenze sono scansionate in un passaggio separato e non bloccante.
• Accessibilità. L'interfaccia soddisfa WCAG 2.2 AA.

Versioning e release

Questo progetto segue il Semantic Versioning e i Conventional Commits. Le modifiche rilevanti sono registrate in CHANGELOG.md. Le regole di contribuzione sono in CONTRIBUTING.md.

Creare una release

1. In CHANGELOG.md, rinomina l'intestazione ## [Unreleased] con la nuova versione e la data odierna, ad es. ## [1.2.3] - 2026-06-01, aggiungi sopra una nuova ## [Unreleased] vuota, e aggiorna i riferimenti ai link in fondo al file.
2. Aggiorna "version" in package.json allo stesso numero.
3. Fai commit su main (un conventional commit, ad es. chore(release): 1.2.3) e push.
4. Tagga il commit e pusha il tag:
   root@kitploit:~

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

La pipeline

Lint, unit test e test end-to-end girano a ogni push. Gli stadi di scan, build e release provengono dai componenti condivisi YouKyi-Infra/ci-infrastructure/ci-catalog (trivy-scan, docker-build, gitlab-release), fissati per versione in .gitlab-ci.yml.

Un tag vX.Y.Z esegue l'intera catena: scan, build dell'immagine, scan dell'immagine, push di vX.Y.Z sul registry GitLab e sui mirror pubblici (ghcr.io, Docker Hub), poi una GitLab Release le cui note sono la sezione ## [X.Y.Z] corrispondente estratta da CHANGELOG.md (una sezione vuota fa fallire il job invece di pubblicare note vuote).

Un push su main esegue la stessa pipeline meno lo stadio di release, e il job dell'immagine gira solo quando è cambiato un file che influisce sulla build, così un push di soli docs o config non ricostruisce l'immagine.

Le dipendenze sono mantenute aggiornate da Renovate, che estende il preset condiviso Renovate-Bot/renovate-config (vedi renovate.json).

Licenza

MIT