Pourquoi c'est sécurisé, expliqué simplement
Pas de jargon inutile : voici, étape par étape, comment Gitfed protège votre code — du transport jusqu'à l'identité de vos collaborateurs.
Uniquement du SSH, jamais du git en HTTP
Gitfed n'expose aucun protocole git par HTTP. Toute lecture ou écriture passe par SSH — un protocole éprouvé depuis 25 ans, avec une seule porte d'entrée à surveiller plutôt que deux.
Des certificats de courte durée, pas des mots de passe partagés
Chaque instance génère sa propre autorité de certification. Votre instance signe un certificat prouvant qui vous êtes, valable 24h par défaut — jamais un secret longue durée à faire fuiter.
La confiance entre instances est explicite, jamais automatique
La première fois qu'une instance inconnue apparaît, Gitfed consulte sa fiche publique (/.well-known/gitfed.json) puis met sa clé en attente — un administrateur doit l'approuver avant que le moindre accès soit accordé. La découverte est aussi limitée à 10 nouveaux domaines par minute, pour éviter tout abus.
L'accès web et l'accès git ne partagent rien
Le mot de passe de l'interface web n'a rien à voir avec vos accès git : il est haché (bcrypt), jamais stocké en clair, et n'ouvre qu'une session web opaque, à durée limitée. Un `git push` ne dépend jamais de ce mot de passe — uniquement de votre clé SSH ou de votre certificat.