**Langues :** [English](README.md) · 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`](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`](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`](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`](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`](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`](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`](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`](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`](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`](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`](CHANGELOG.md) | Historique des versions (également servi sur `/changelog` dans l'interface web). |
| [`THIRD_PARTY_LICENSES.md`](THIRD_PARTY_LICENSES.md) | Chaque dépendance Go et sa licence. |

## Le faire tourner en local

```sh
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 :

```sh
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`](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`](deploy/k8s/README.md). Chaque mise à jour après la
première doit passer par [`deploy/update.sh`](deploy/update.sh), qui
incrémente la version, construit et importe une image taguée, et effectue
le déploiement :

```sh
# 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`](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`](deploy/k8s/README.md#backups).

## Licence

[GNU AGPLv3](LICENSE) — 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é.