El catálogo vive en un único registro (src/lib/tools.ts) que controla la barra de navegación y la cuadrícula de inicio.

Alrededor de las herramientas en sí:

• Pega cualquier cosa en la página de inicio. El artefacto se reconoce por sus bytes (etiqueta PEM o cabecera DER, consulta src/lib/pki/detect.ts) y se abre en la herramienta que lo lee.
• Un artefacto en la herramienta equivocada lo indica y ofrece la correcta, transfiriendo su contenido. La transferencia ocurre en memoria, nunca a través de la URL, por lo que se mantiene fuera de los archivos de historial, los registros de proxy y la sincronización de marcadores.
• "El mismo artefacto en" bajo un resultado lo transfiere a las otras herramientas que lo leen, de modo que un solo pegado responde a varias preguntas.
• Una banda de veredicto responde a la pregunta para la que existe la herramienta antes de cualquier fila de detalle, y los valores que acaban citados en un ticket se copian con un clic.
• Cada herramienta acepta un artefacto pegado o un archivo subido, e incluye una entrada de ejemplo para que puedas probarla sin uno. / coloca el cursor en la entrada.

Privacidad verificable

La afirmación "nunca sale de tu navegador" es verificable desde dentro de la página:

• Cada caja de entrada incluye un panel Verificar que relee la directiva connect-src de la propia página desde la política con la que fue servida, cuenta las peticiones capaces de sacar datos desde que pegaste, y ejecuta un intento en vivo que el navegador rechaza delante de ti, citando la directiva que lo bloqueó.
• Una clave privada pegada se nombra y se oculta: la caja indica qué contiene y que no ha salido de la página, con Bórrala y Muéstrala de todos modos. Nada se decodifica, transmite ni almacena.
• Abre la pestaña de red de tu navegador mientras decodificas un certificado: no verás ni una sola petición.

Ejecútalo

Ejecuta siempre una etiqueta de versión fijada e inmutable (vX.Y.Z), nunca latest: una etiqueta móvil no puede auditarse ni revertirse. Para la garantía más fuerte, fija el digest de la imagen (...@sha256:...).

Luego abre http://localhost:8080.

Imágenes públicas

Cada versión se publica, bajo la misma etiqueta inmutable vX.Y.Z, en:

Autoalojamiento con Docker Compose

El repositorio incluye un docker-compose.yml totalmente endurecido (sistema de archivos raíz de solo lectura, capacidades eliminadas, límites de memoria y CPU); usa ese archivo directamente en lugar de este ejemplo mínimo.

La imagen se construye a partir de nginx:alpine-slim, pesa unos 25 MB, escucha en el puerto no privilegiado 8080 y se ejecuta como usuario no root.

Desarrollo local

Requiere Node 24 (la versión con la que se construyen la imagen y CI) y pnpm 11. La versión exacta de pnpm está fijada por el campo packageManager de package.json, por lo que corepack enable es suficiente para obtenerla.

Construir la imagen Docker

Cómo funciona

• SvelteKit 2 + TypeScript, construido con adapter-static a HTML/JS plano: cada ruta se prerrenderiza y no hay runtime de Node en producción.
• TailwindCSS para el estilo, sobre el sistema de diseño youkyi: claro por defecto, oscuro como tema distintivo (la elección se conserva).
• Todo el análisis reside en funciones puras y testeables bajo src/lib/pki/, sin importación de 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 y sign.ts. Cada ruta bajo src/routes/ es una fina capa de UI alrededor de ellas.
• @peculiar/x509 v2 construye sus objetos a través de tsyringe, que necesita un polyfill de metadatos Reflect en el lado del consumidor, por lo que @abraham/reflection se importa antes que él en cada módulo que usa la biblioteca.
• PKCS#7 y PKCS#12 pasan por pkijs, cuyo motor de Web Crypto se registra una vez en src/lib/pki/engine.ts.
• Las pruebas unitarias residen en tests/pki/ (Vitest) y las pruebas de navegador en e2e/ (Playwright). Los fixtures son raíces públicas reales (ISRG Root X1/X2) más una cadena EC y un CSR generados, consulta scripts/generate-fixtures.mjs.

Postura de seguridad

• Sin salida de red desde la aplicación. La Content-Security-Policy es emitida por SvelteKit como una etiqueta <meta> con connect-src 'none'; nginx añade frame-ancestors 'none', X-Frame-Options, X-Content-Type-Options, Referrer-Policy: no-referrer, una Permissions-Policy restrictiva y las cabeceras de aislamiento entre orígenes. La demo de Vercel envía el mismo conjunto de cabeceras (consulta vercel.json).
• Límites ante entradas hostiles. Cada decodificador rechaza una entrada superior a 4 MB, y el recorredor ASN.1 está acotado en número de nodos y profundidad de anidamiento, de modo que un artefacto malformado no puede colgar la pestaña.
• Runtime endurecido. nginx se ejecuta como usuario no root en el puerto 8080; el docker-compose.yml incluido añade un sistema de archivos raíz de solo lectura, cap_drop: ALL, no-new-privileges y límites de recursos.
• Cadena de suministro. Ambas imágenes base están fijadas a digests inmutables mantenidos al día por Renovate. CI falla ante un hallazgo HIGH/CRITICAL corregible, tanto en el repositorio (trivy fs) como en la imagen recién construida, que también se rechaza cuando su SO base está al final de su vida útil, de modo que nunca se publica una imagen vulnerable. Las licencias se escanean en una pasada separada y no bloqueante.
• Accesibilidad. La interfaz cumple WCAG 2.2 AA.

Versionado y publicaciones

Este proyecto sigue Semantic Versioning y Conventional Commits. Los cambios notables se registran en CHANGELOG.md. Las reglas de contribución están en CONTRIBUTING.md.

Publicar una versión

1. En CHANGELOG.md, renombra el encabezado ## [Unreleased] a la nueva versión con la fecha de hoy, p. ej. ## [1.2.3] - 2026-06-01, añade un nuevo ## [Unreleased] vacío encima, y actualiza las referencias de enlaces al final del archivo.
2. Sube "version" en package.json al mismo número.
3. Haz commit en main (un commit convencional, p. ej. chore(release): 1.2.3) y haz push.
4. Etiqueta el commit y haz push de la etiqueta:
   root@kitploit:~

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

El pipeline

Lint, pruebas unitarias y pruebas de extremo a extremo se ejecutan en cada push. Las etapas de escaneo, construcción y publicación provienen de los componentes compartidos YouKyi-Infra/ci-infrastructure/ci-catalog (trivy-scan, docker-build, gitlab-release), fijados por versión en .gitlab-ci.yml.

Una etiqueta vX.Y.Z ejecuta toda la cadena: escaneo, construcción de imagen, escaneo de imagen, push de vX.Y.Z al registro de GitLab y a los espejos públicos (ghcr.io, Docker Hub), luego una GitLab Release cuyas notas son la sección ## [X.Y.Z] correspondiente extraída de CHANGELOG.md (una sección vacía hace fallar el job en lugar de publicar notas vacías).

Un push a main ejecuta el mismo pipeline menos el paso de publicación, y el job de imagen solo se ejecuta cuando cambió un archivo que afecta a la construcción, de modo que un push solo de documentación o configuración no reconstruye la imagen.

Las dependencias se mantienen actualizadas por Renovate, que extiende el preset compartido Renovate-Bot/renovate-config (consulta renovate.json).

Licencia

MIT