Gitfed
bastien-mrq/gitfed / README.fr.md
README.fr.md Code Preview

Langues : English · Français

gitfed

Un serveur git auto-hébergé et fédéré, pour celles et ceux qui veulent que leur code et leurs données leur appartiennent vraiment — sans renoncer à pouvoir collaborer avec qui que ce soit, où qu'iel héberge son instance.

Pourquoi gitfed existe

La plupart des solutions d'hébergement git imposent un choix : garder son code sur une infrastructure qu'on ne contrôle pas, ou renoncer à collaborer avec quiconque en dehors de son propre serveur. gitfed existe pour supprimer ce compromis.

  • Propriété — vos dépôts, vos utilisateurs, votre base de données, sur une machine que vous contrôlez. Aucune plateforme ne peut limiter votre accès, exploiter votre code, ou vous en couper l'accès.
  • Fédération — votre instance peut faire confiance à d'autres instances, comme les serveurs de mail se font confiance entre eux. Une personne sur une instance gitfed complètement différente peut recevoir un accès à l'un de vos dépôts sans jamais créer de compte chez vous.
  • Contrôle — chaque dépôt est explicitement public ou privé, chaque collaborateur a un rôle explicite (lecture/écriture/admin), et chaque relation de confiance entre instances est également explicite — rien n'est accordé par défaut simplement parce qu'une requête est arrivée.

gitfed n'essaie pas de rivaliser avec GitHub ou GitLab sur le nombre de fonctionnalités. L'interface web (navigateur de fichiers, gestion autonome des dépôts, panneau admin) existe pour rendre ce modèle d'identité utilisable au quotidien — le modèle d'identité est le vrai sujet.

Comment ça marche, en un paragraphe

Chaque instance gitfed fait tourner sa propre autorité de certification. Quand vous poussez ou récupérez du code, votre instance d'origine signe un certificat SSH de courte durée qui prouve qui vous êtes. Toute instance qui a choisi de faire confiance à l'autorité de certification de votre instance d'origine accepte ce certificat — pas de second compte, pas de mot de passe partagé, pas d'inscription par instance. L'explication complète, avec schémas, est dans docs/HOW_IT_WORKS.md, et la même explication est aussi servie en direct sur /security sur n'importe quelle instance en fonctionnement.

Ce qui est inclus

  • gitfed-server — serveur SSH (opérations git + émission de certificats) et le point de terminaison de fédération /.well-known/gitfed.json.
  • gitfed-web — l'interface web : un navigateur de dépôts public, et, derrière une connexion par mot de passe, la gestion autonome (vos propres clés et dépôts), les merge requests avec revue et fil de discussion, et une section admin, en français ou en anglais.
  • gitfed-tui — un outil d'administration en terminal ; le seul moyen d'amorcer le tout premier compte.
  • gitfed-renew-cert — un petit outil client pour renouveler votre propre certificat avant son expiration.

Pour aller plus loin

Doc Contenu
INSTALL.md Installation étape par étape sur un VPS tout neuf, d'une machine vide jusqu'à une instance qui tourne — sans supposer k3s/cert-manager déjà en place.
FEDERATION.md Comment faire fonctionner la fédération pour de vrai : prérequis, octroi d'accès, l'étape d'approbation de confiance qu'on oublie facilement, et obtention d'un certificat.
docs/HOW_IT_WORKS.md Le modèle de fédération/identité de bout en bout : certificats, magasin de confiance, ACL, un vrai push détaillé étape par étape.
docs/ARCHITECTURE.md Comment le code est organisé : les quatre binaires, les paquets internal/, pourquoi il existe un socket RPC d'administration, la topologie Kubernetes.
docs/security/AUDIT.md L'audit de sécurité pré-production et ce qui en a été corrigé.
docs/security/AUDIT-2026-07-29.md Audit de suivi couvrant le clone HTTPS anonyme, les notifications fédérées et les dépôts épinglés ajoutés depuis.
docs/security/AUDIT-2026-07-29b.md Audit des merge requests — a trouvé et corrigé une faille critique non authentifiée (écriture de fichier arbitraire via des hash de commit / noms de branche forgés), plus deux correctifs de moindre sévérité.
DESIGN.md Le document de conception d'origine — le « pourquoi » derrière l'architecture, écrit avant le début de l'implémentation.
ROADMAP.md Ce qui a été volontairement laissé de côté pour la V1 et pourquoi, ce qui est rejeté purement et simplement, et ce qui pourrait venir ensuite.
CHANGELOG.md Historique des versions (également servi sur /changelog dans l'interface web).
THIRD_PARTY_LICENSES.md Chaque dépendance Go et sa licence.

Le faire tourner en local

go build -o bin/gitfed-server ./cmd/gitfed-server
go build -o bin/gitfed-web    ./cmd/gitfed-web
go build -o bin/gitfed-tui    ./cmd/gitfed-tui

./bin/gitfed-server -init localhost -data-dir data -config gitfed.json
# éditez gitfed.json si vous voulez d'autres ports (par défaut : ssh :2222, http :8443)
./bin/gitfed-server -config gitfed.json &

./bin/gitfed-tui -config gitfed.json
# Users -> a (add user) : nom d'utilisateur, votre clé publique SSH, un mot de passe, admin : y

./bin/gitfed-web -config gitfed.json &
# ouvrez http://localhost:8088, connectez-vous avec ce que vous venez de créer

Le clonage/push passe toujours par SSH :

git clone ssh://git@localhost:2222/<user>/<repo>

Déployer pour de vrai

Tu pars d'un VPS tout neuf, sans rien d'installé (ni k3s, ni cert-manager) ? INSTALL.md reprend tout ça depuis zéro, étape par étape — ou lance gitfed-install (go build -o gitfed-install ./cmd/gitfed-install), un assistant terminal qui fait les mêmes étapes à ta place, détecte ce qui est déjà installé, et diagnostique lui-même un pod bloqué en ErrImageNeverPull.

Si k3s/Traefik/cert-manager tournent déjà chez toi, l'explication complète — manifestes, pourquoi le pod est formé ainsi, DNS, amorçage du premier compte — est dans deploy/k8s/README.md. Chaque mise à jour après la première doit passer par deploy/update.sh, qui incrémente la version, construit et importe une image taguée, et effectue le déploiement :

# ajoutez d'abord une section "## X.Y.Z" à CHANGELOG.md décrivant le changement
deploy/update.sh          # incrément patch
deploy/update.sh minor    # ou : major, ou une version explicite X.Y.Z

Sauvegardes

Tout ce qui compte vit sur un seul volume persistant : la base de données (utilisateurs, dépôts, ACL, sessions, magasin de confiance, journal d'audit, révocations de certificats), la clé de l'autorité de certification de l'instance, la clé d'hôte SSH, et les dépôts bare eux-mêmes. Perdre la clé de la CA invalide tous les certificats jamais émis par cette instance et casse toutes les relations de confiance fédérées qui pointent vers elle — il n'y a pas de récupération possible en dehors de tout reconstruire depuis zéro. Sauvegardez le volume entier, pas seulement les données git.

Pour le déploiement Kubernetes, deploy/backup.sh automatise ça — capture tout le volume dans une archive datée téléchargée depuis le serveur, avec purge automatique. La procédure de restauration est dans deploy/k8s/README.md.

Licence

GNU AGPLv3 — la licence à copyleft réseau : si vous faites tourner une version modifiée de gitfed en tant que service pour d'autres personnes, vous êtes tenu·e de leur rendre le code source de vos modifications accessible, même sans jamais distribuer le binaire. C'est un choix délibéré, pas une valeur par défaut — il vise à garder les améliorations d'une instance dérivée de gitfed dans l'écosystème, plutôt que de les voir enfermées derrière un service hébergé fermé.