O catálogo vive num único registo (src/lib/tools.ts) que alimenta a barra de navegação e a grelha inicial.

Em torno das próprias ferramentas:

• Cole qualquer coisa na página inicial. O artefacto é reconhecido pelos seus bytes (etiqueta PEM ou cabeçalho DER, veja src/lib/pki/detect.ts) e abre na ferramenta que o lê.
• Um artefacto na ferramenta errada di-lo e oferece a correta, transportando o seu conteúdo. A transferência acontece em memória, nunca através do URL, por isso fica fora de ficheiros de histórico, registos de proxy e sincronizações de marcadores.
• "Same artefact in" por baixo de um resultado transporta-o para as outras ferramentas que o leem, para que uma colagem responda a várias perguntas.
• Uma faixa de veredicto responde à pergunta para a qual a ferramenta existe antes de qualquer linha de detalhe, e os valores que acabam citados num ticket copiam-se com um clique.
• Cada ferramenta aceita um artefacto colado ou um ficheiro carregado, e inclui uma entrada de exemplo para poder experimentar sem um. / coloca o cursor na entrada.

Privacidade verificável

A afirmação "nunca sai do seu navegador" é verificável a partir de dentro da página:

• Cada caixa de entrada tem um painel Verify que relê a própria diretiva connect-src da página a partir da política com que foi servida, conta os pedidos capazes de transportar dados para fora desde que colou, e executa uma tentativa ao vivo que o navegador recusa à sua frente, citando a diretiva que a bloqueou.
• Uma chave privada colada é nomeada e velada: a caixa diz o que contém e que não saiu da página, com Clear it e Show it anyway. Nada é descodificado, transmitido ou armazenado.
• Abra o separador de rede do seu navegador enquanto descodifica um certificado: não verá um único pedido.

Executá-lo

Execute sempre uma tag de release fixa e imutável (vX.Y.Z), nunca latest: uma tag móvel não pode ser auditada nem revertida. Para a garantia mais forte, fixe o digest da imagem (...@sha256:...).

Depois abra http://localhost:8080.

Imagens públicas

Cada release é publicada, sob a mesma tag imutável vX.Y.Z, em:

Auto-hospedar com Docker Compose

O repositório inclui um docker-compose.yml totalmente endurecido (sistema de ficheiros raiz só de leitura, capacidades removidas, limites de memória e CPU); use esse ficheiro diretamente em vez deste exemplo mínimo.

A imagem é construída a partir de nginx:alpine-slim, pesa cerca de 25 MB, escuta na porta não privilegiada 8080 e corre como utilizador não-root.

Desenvolvimento local

Requer Node 24 (a versão com que a imagem e o CI são construídos) e pnpm 11. A versão exata do pnpm é fixada pelo campo packageManager de package.json, por isso corepack enable é suficiente para o obter.

Construir a imagem Docker

Como funciona

• SvelteKit 2 + TypeScript, construído com adapter-static para HTML/JS simples: cada rota é pré-renderizada e não há runtime Node em produção.
• TailwindCSS para estilização, sobre o design system youkyi: claro por omissão, escuro como tema de assinatura (a escolha é persistida).
• Toda a análise vive em funções puras e testáveis sob src/lib/pki/, sem importação 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 e sign.ts. Cada rota sob src/routes/ é uma fina camada de UI em torno delas.
• @peculiar/x509 v2 constrói os seus objetos através de tsyringe, que precisa de um polyfill de metadados Reflect do lado do consumidor, por isso @abraham/reflection é importado antes dele em cada módulo que usa a biblioteca.
• PKCS#7 e PKCS#12 passam por pkijs, cujo motor Web Crypto é registado uma vez em src/lib/pki/engine.ts.
• Os testes unitários vivem em tests/pki/ (Vitest) e os testes de navegador em e2e/ (Playwright). Os fixtures são raízes públicas reais (ISRG Root X1/X2) mais uma cadeia EC e CSR geradas, veja scripts/generate-fixtures.mjs.

Postura de segurança

• Sem saída de rede a partir da aplicação. A Content-Security-Policy é emitida pelo SvelteKit como uma tag <meta> com connect-src 'none'; o nginx adiciona frame-ancestors 'none', X-Frame-Options, X-Content-Type-Options, Referrer-Policy: no-referrer, uma Permissions-Policy restritiva e os cabeçalhos de isolamento cross-origin. A demonstração Vercel envia o mesmo conjunto de cabeçalhos (veja vercel.json).
• Limites para entradas hostis. Cada descodificador rejeita uma entrada superior a 4 MB, e o percorredor ASN.1 é limitado em número de nós e profundidade de aninhamento, para que um artefacto malformado não possa bloquear o separador.
• Runtime endurecido. O nginx corre como utilizador não-root na porta 8080; o docker-compose.yml incluído adiciona um sistema de ficheiros raiz só de leitura, cap_drop: ALL, no-new-privileges e limites de recursos.
• Cadeia de fornecimento. Ambas as imagens base estão fixadas a digests imutáveis mantidos atualizados pelo Renovate. O CI falha perante uma descoberta HIGH/CRITICAL corrigível, tanto no repositório (trivy fs) como na imagem recém-construída, que também é rejeitada quando o seu SO base está em fim de vida, para que uma imagem vulnerável nunca seja publicada. As licenças são analisadas numa passagem separada e não bloqueante.
• Acessibilidade. A interface cumpre o WCAG 2.2 AA.

Versionamento e releases

Este projeto segue o Semantic Versioning e o Conventional Commits. As alterações notáveis são registadas em CHANGELOG.md. As regras de contribuição estão em CONTRIBUTING.md.

Preparar uma release

1. Em CHANGELOG.md, renomeie o cabeçalho ## [Unreleased] para a nova versão com a data de hoje, por exemplo ## [1.2.3] - 2026-06-01, adicione um novo ## [Unreleased] vazio acima dele, e atualize as referências de links no fundo do ficheiro.
2. Atualize "version" em package.json para o mesmo número.
3. Faça commit em main (um commit convencional, por exemplo chore(release): 1.2.3) e faça push.
4. Marque o commit com uma tag e faça push da tag:
   root@kitploit:~

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

O pipeline

Lint, testes unitários e testes end-to-end correm em cada push. As fases de scan, build e release vêm dos componentes partilhados YouKyi-Infra/ci-infrastructure/ci-catalog (trivy-scan, docker-build, gitlab-release), fixados por versão em .gitlab-ci.yml.

Uma tag vX.Y.Z executa toda a cadeia: scan, build da imagem, scan da imagem, push de vX.Y.Z para o registo GitLab e para os espelhos públicos (ghcr.io, Docker Hub), depois uma GitLab Release cujas notas são a secção ## [X.Y.Z] correspondente extraída de CHANGELOG.md (uma secção vazia faz falhar a tarefa em vez de publicar notas vazias).

Um push para main executa o mesmo pipeline menos a fase de release, e a tarefa da imagem só corre quando um ficheiro que afeta a build mudou, para que um push apenas de docs ou config não reconstrua a imagem.

As dependências são mantidas atualizadas pelo Renovate, que estende o preset partilhado Renovate-Bot/renovate-config (veja renovate.json).

Licença

MIT