Le catalogue vit dans un registre unique (src/lib/tools.ts) qui pilote la barre de navigation et la grille d'accueil.

Autour des outils eux-mêmes :

• Collez n'importe quoi sur la page d'accueil. L'artefact est reconnu par ses octets (label PEM ou en-tête DER, voir src/lib/pki/detect.ts) et s'ouvre dans l'outil qui le lit.
• Un artefact dans le mauvais outil le signale et propose le bon, en transférant son contenu. Le transfert se fait en mémoire, jamais via l'URL, il reste donc hors des fichiers d'historique, des logs de proxy et des synchronisations de favoris.
• « Même artefact dans » sous un résultat le transfère vers les autres outils qui le lisent, ainsi un seul collage répond à plusieurs questions.
• Une bande de verdict répond à la question pour laquelle l'outil existe avant toute ligne de détail, et les valeurs qui finissent citées dans un ticket se copient en un clic.
• Chaque outil accepte un artefact collé ou un fichier téléversé, et fournit un exemple d'entrée pour l'essayer sans en avoir un. / place le curseur dans le champ de saisie.

Confidentialité vérifiable

L'affirmation « il ne quitte jamais votre navigateur » est vérifiable depuis la page elle-même :

• Chaque zone de saisie porte un panneau Vérifier qui relit la directive connect-src de la page depuis la politique avec laquelle elle a été servie, compte les requêtes capables d'exfiltrer des données depuis votre collage, et exécute une tentative en direct que le navigateur refuse devant vous, en citant la directive qui l'a bloquée.
• Une clé privée collée est nommée et voilée : la zone indique ce qu'elle contient et qu'elle n'a pas quitté la page, avec Effacer et Afficher quand même. Rien n'est décodé, transmis ou stocké.
• Ouvrez l'onglet réseau de votre navigateur pendant le décodage d'un certificat : vous ne verrez pas une seule requête.

L'exécuter

Exécutez toujours un tag de release épinglé et immuable (vX.Y.Z), jamais latest : un tag mouvant ne peut être audité ni annulé. Pour la garantie la plus forte, épinglez le digest de l'image (...@sha256:...).

Puis ouvrez http://localhost:8080.

Images publiques

Chaque release est publiée, sous le même tag immuable vX.Y.Z, sur :

Auto-hébergement avec Docker Compose

Le dépôt fournit un docker-compose.yml entièrement durci (système de fichiers racine en lecture seule, capacités supprimées, limites de mémoire et de CPU) ; utilisez ce fichier directement plutôt que cet exemple minimal.

L'image est construite à partir de nginx:alpine-slim, pèse environ 25 Mo, écoute sur le port non privilégié 8080 et s'exécute en tant qu'utilisateur non-root.

Développement local

Nécessite Node 24 (la version avec laquelle l'image et la CI sont construites) et pnpm 11. La version exacte de pnpm est épinglée par le champ packageManager de package.json, donc corepack enable suffit pour l'obtenir.

Construire l'image Docker

Comment ça fonctionne

• SvelteKit 2 + TypeScript, construit avec adapter-static en HTML/JS pur : chaque route est prérendue et il n'y a aucun runtime Node en production.
• TailwindCSS pour le style, sur le design system youkyi : clair par défaut, sombre comme thème signature (le choix est persisté).
• Tout l'analyse réside dans des fonctions pures et testables sous src/lib/pki/, sans 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 et sign.ts. Chaque route sous src/routes/ est une fine coquille d'interface autour d'elles.
• @peculiar/x509 v2 construit ses objets via tsyringe, qui nécessite un polyfill de métadonnées Reflect côté consommateur, donc @abraham/reflection est importé avant lui dans chaque module qui utilise la bibliothèque.
• PKCS#7 et PKCS#12 passent par pkijs, dont le moteur Web Crypto est enregistré une fois dans src/lib/pki/engine.ts.
• Les tests unitaires résident dans tests/pki/ (Vitest) et les tests navigateur dans e2e/ (Playwright). Les fixtures sont de vraies racines publiques (ISRG Root X1/X2) plus une chaîne EC et un CSR générés, voir scripts/generate-fixtures.mjs.

Posture de sécurité

• Aucune sortie réseau depuis l'application. La Content-Security-Policy est émise par SvelteKit sous forme de balise <meta> avec connect-src 'none' ; nginx ajoute frame-ancestors 'none', X-Frame-Options, X-Content-Type-Options, Referrer-Policy: no-referrer, une Permissions-Policy restrictive et les en-têtes d'isolation cross-origin. La démo Vercel envoie le même jeu d'en-têtes (voir vercel.json).
• Limites face aux entrées hostiles. Chaque décodeur rejette une entrée de plus de 4 Mo, et le parcoureur ASN.1 est borné en nombre de nœuds et en profondeur d'imbrication, ainsi un artefact malformé ne peut pas bloquer l'onglet.
• Runtime durci. nginx s'exécute en tant qu'utilisateur non-root sur le port 8080 ; le docker-compose.yml fourni ajoute un système de fichiers racine en lecture seule, cap_drop: ALL, no-new-privileges et des limites de ressources.
• Chaîne d'approvisionnement. Les deux images de base sont épinglées à des digests immuables maintenus à jour par Renovate. La CI échoue sur une vulnérabilité HIGH/CRITICAL corrigeable, à la fois sur le dépôt (trivy fs) et sur l'image fraîchement construite, qui est également rejetée lorsque son OS de base est en fin de vie, ainsi une image vulnérable n'est jamais poussée. Les licences sont scannées dans une passe séparée et non bloquante.
• Accessibilité. L'interface respecte WCAG 2.2 AA.

Versionnage et releases

Ce projet suit le Semantic Versioning et les Conventional Commits. Les changements notables sont consignés dans CHANGELOG.md. Les règles de contribution se trouvent dans CONTRIBUTING.md.

Publier une release

1. Dans CHANGELOG.md, renommez le titre ## [Unreleased] avec la nouvelle version et la date du jour, par ex. ## [1.2.3] - 2026-06-01, ajoutez un nouveau ## [Unreleased] vide au-dessus, et mettez à jour les références de liens en bas du fichier.
2. Incrémentez "version" dans package.json au même numéro.
3. Committez sur main (un commit conventionnel, par ex. chore(release): 1.2.3) et poussez.
4. Taguez le commit et poussez le tag :
   root@kitploit:~

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

Le pipeline

Lint, tests unitaires et tests de bout en bout s'exécutent à chaque push. Les étapes de scan, build et release proviennent des composants partagés YouKyi-Infra/ci-infrastructure/ci-catalog (trivy-scan, docker-build, gitlab-release), épinglés par version dans .gitlab-ci.yml.

Un tag vX.Y.Z exécute toute la chaîne : scan, build de l'image, scan de l'image, push de vX.Y.Z vers le registre GitLab et vers les miroirs publics (ghcr.io, Docker Hub), puis une GitLab Release dont les notes sont la section ## [X.Y.Z] correspondante extraite de CHANGELOG.md (une section vide fait échouer le job plutôt que de publier des notes vides).

Un push sur main exécute le même pipeline moins l'étape de release, et le job d'image ne s'exécute que lorsqu'un fichier affectant le build a changé, ainsi un push de docs ou de config uniquement ne reconstruit pas l'image.

Les dépendances sont maintenues à jour par Renovate, qui étend le preset partagé Renovate-Bot/renovate-config (voir renovate.json).

Licence

MIT