Installer feint : release vérifiée, Homebrew, mise ou conteneur

Trois chemins mènent à feint, et ils ne servent pas le même besoin. L'image de conteneur ne demande rien à installer et convient à une CI ; le binaire vérifié est le chemin recommandé sur un poste, et le seul qui donne accès aux machines réelles ; l'action GitHub installe ce binaire dans un pipeline en vérifiant sa somme de contrôle avant de l'exécuter. Cette page détaille les trois, et la vérification d'intégrité qui va avec.

Ce que vous allez obtenir

À la fin de cette page, feint version répondra v0.13.0 sur votre machine, installé par le canal qui correspond à votre exigence de vérification, et vous saurez le lancer comme service dans un pipeline.

Choisir le canal d'installation adapté à votre usage.
Vérifier qui a publié le binaire avant de lui faire confiance.
Lancer l'émulateur comme service dans GitHub Actions ou GitLab CI.
Savoir quand une nouvelle version est publiée, sans appel réseau imposé.

Quel chemin choisir

Besoin	Chemin	Machines réelles
Essayer en une commande	Image de conteneur	non
Pipeline CI avec un service	Image de conteneur	non
Pipeline GitHub Actions sans conteneur	Action `setup-feint`	non
Poste personnel, en une commande	Binaire par Homebrew	oui, avec Incus
Outils épinglés par projet	Binaire par mise	oui, avec Incus
Poste sensible ou machine partagée	Binaire de la release vérifiée	oui, avec Incus
Machines réelles, SSH, isolation OVN	Binaire, quel que soit le canal	oui

L'image ne fait tourner aucune machine, et c'est assumé : elle exécute feint serve --vm off, parce que les machines réelles sont une propriété du binaire sur un hôte Incus. Une image qui prétendrait le contraire serait la demi-vérité que ce projet refuse ailleurs.

Installer le binaire

Trois chemins mènent au même binaire, et ils ne vérifient pas la même chose. Le tableau ci-dessous dit ce que chacun contrôle avant de vous laisser exécuter le programme, parce que c'est le seul critère qui les sépare vraiment : ils installent tous la même version publiée.

Chemin	Ce qui est vérifié	Pour qui
Release vérifiée	signature Sigstore de la liste, puis somme de contrôle des octets	un poste sensible, une machine partagée, un runner
Homebrew	la somme SHA-256 que la formule porte, pas la signature	un poste personnel, en une commande
mise	les attestations de provenance GitHub, vérifiées à l'installation	qui épingle déjà ses outils par projet

Téléchargez le binaire de la version, vérifiez qui l'a publié, puis vérifiez les octets. L'ordre compte : une somme de contrôle ne prouve rien si vous ne savez pas qui a produit la liste qui la contient.

Récupérer les artefacts de la version.

base=https://github.com/stephrobert/feint/releases/download/v0.13.0

curl -fsSLO "$base/feint-linux-amd64"
curl -fsSLO "$base/checksums.txt"
curl -fsSLO "$base/checksums.txt.cosign.bundle"

Vérifier la signature de la liste de sommes, avant de faire confiance à une seule ligne de son contenu.
Fenêtre de terminal
```
cosign verify-blob --bundle checksums.txt.cosign.bundle \
  --certificate-identity-regexp '^https://github\.com/stephrobert/feint/\.github/workflows/release\.yml@refs/tags/v' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  checksums.txt
```
La sortie attendue tient en deux mots : Verified OK. Toute autre réponse doit arrêter l'installation. Notez la précision du motif d'identité : il nomme le workflow de publication et le préfixe de tag, là où un motif large accepterait n'importe quel workflow du dépôt. Un dépôt compromis dont un workflow secondaire signerait un binaire ne passerait pas ce contrôle.
Vérifier les octets contre la liste signée.
Fenêtre de terminal
```
sha256sum -c checksums.txt --ignore-missing
```
Le résultat attendu est feint-linux-amd64: OK. Sans --ignore-missing, la commande échoue sur toutes les plateformes que vous n'avez pas téléchargées, ce qui ressemble à tort à un binaire corrompu.
Installer le binaire et confirmer la version.
Fenêtre de terminal
```
install -m 0755 feint-linux-amd64 ~/.local/bin/feint
feint version
```
La sortie doit afficher v0.13.0.

Si vous préférez la provenance à la signature, gh vérifie quel workflow et quel commit ont produit le binaire :

gh attestation verify feint-linux-amd64 --repo stephrobert/feint

Le chemin le plus court, sur macOS comme sur Linux.

brew install stephrobert/feint/feint
feint version

La formule est produite par la publication elle-même, à partir des sommes que la release a signées : la valeur que Homebrew vérifie est donc bien celle du binaire officiel.

Une nuance à connaître plutôt qu'à ignorer : Homebrew contrôle la somme, pas la signature. Il vous dit que les octets correspondent à ce que la formule annonce, pas qui les a publiés. C'est suffisant sur un poste personnel, et c'est précisément la différence avec l'onglet précédent. Aucune version n'est nommée ici volontairement : brew résout la formule courante du dépôt de formules.

Si vous gérez déjà vos outils avec mise, feint s'installe comme les autres, avec sa version épinglée dans votre configuration.

mise use -g github:stephrobert/feint@0.13.0
feint version

Le backend github fait plus que télécharger : il vérifie les attestations de provenance publiées par le dépôt avant d'installer.

mise github:stephrobert/feint@0.13.0     [2/3] ✓ GitHub attestations verified
mise github:stephrobert/feint@0.13.0   ✓ installed
v0.13.0

Pour essayer sans rien installer durablement, mise x exécute la version demandée le temps d'une seule commande :

mise x github:stephrobert/feint@0.13.0 -- feint version

Le backend ubi: fonctionne encore et donne le même binaire, mais mise le signale comme déprécié au profit de github:.

Lancer l'émulateur en conteneur

Une image est publiée à chaque version, et elle sert le plan de contrôle seul. C'est le chemin le plus court : un service, un port, aucun binaire à installer sur la machine.

docker run --rm -p 127.0.0.1:4599:4599 \
  ghcr.io/stephrobert/feint:v0.13.0@sha256:d46639ac7c7a0fa2b6b69d0c5d74bdca0757e3124675563209e8ada58e6a6040
curl -s http://127.0.0.1:4599/_feint/health | jq -c '{status, machines}'

{"status":"ok","machines":"none"}

Dans un pipeline, l'image se déclare comme un service ordinaire, et aucun secret n'est à ajouter : c'est tout l'intérêt pour une équipe qui refuse de poser des identifiants cloud dans sa CI.

services:
  feint:
    image: ghcr.io/stephrobert/feint:v0.13.0@sha256:d46639ac7c7a0fa2b6b69d0c5d74bdca0757e3124675563209e8ada58e6a6040
    ports:
      - 4599:4599

Le runner retient les étapes jusqu'à ce que le contrôle de santé de l'image réponde, donc la première étape peut parler à l'émulateur immédiatement.

services:
  - name: ghcr.io/stephrobert/feint:v0.13.0@sha256:d46639ac7c7a0fa2b6b69d0c5d74bdca0757e3124675563209e8ada58e6a6040
    alias: feint

Sans conteneur, l'action officielle installe le binaire publié, vérifie sa somme de contrôle avant de l'exécuter, et attend que l'émulateur réponde.

- uses: stephrobert/setup-feint@b7eba1d4fcaccf65cf9124bf97a0d995996709b9 # v1.0.0
  with:
    version: 0.13.0
    provider: scaleway   # exporte ce que le client officiel attend

L'image se vérifie comme les binaires, avec la même identité de workflow :

cosign verify ghcr.io/stephrobert/feint:v0.13.0 \
  --certificate-identity-regexp '^https://github\.com/stephrobert/feint/\.github/workflows/release\.yml@refs/tags/v' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

L'image ne publie pas de latest : une référence mutable ne peut pas être confrontée à une somme de contrôle, et c'est la raison qui vaut aussi pour les binaires. Le contenu est un scratch portant le seul binaire signé, sans interpréteur ni gestionnaire de paquets à l'intérieur.

Les exemples de cette page épinglent le digest en plus du tag, ce qui fige les octets exécutés : le tag dit quelle version, le digest dit quels octets. Il se résout en une commande, à rejouer à chaque nouvelle version :

crane digest ghcr.io/stephrobert/feint:v0.13.0

Savoir qu'une nouvelle version est sortie

feint version --check demande à GitHub si une version plus récente existe, et affiche la commande pour l'installer. Deux principes gouvernent cette commande : rien ne part sur le réseau tant que le drapeau n'est pas tapé, et le binaire ne se met jamais à jour tout seul.

feint version --check

Quand une version plus récente est publiée, la sortie donne la commande d'installation épinglée sur cette version précise. Elle nomme la version, jamais latest : une référence mutable télécharge ce qui est le plus récent au moment de l'appel, et ce contenu ne peut plus être confronté à la somme de contrôle écrite juste en dessous. Si vous êtes déjà à jour, la commande rappelle votre version puis conclut en une ligne :

v0.13.0
this is the latest release

Un binaire compilé depuis les sources porte dev, et une installation par go install porte une pseudo-version horodatée. Ni l'un ni l'autre ne se compare à une étiquette de version, donc l'outil annonce la dernière release sans prétendre que votre exemplaire est périmé.

À retenir

Trois chemins : l'image pour essayer et pour la CI, le binaire pour un poste, l'action pour GitHub Actions.
L'image ne fait tourner aucune machine : les machines réelles restent une propriété du binaire sur un hôte Incus.
La vérification précède l'exécution : signature de la liste, puis sommes de contrôle, puis installation.
Le motif d'identité nomme le workflow de publication, pas seulement le dépôt.
Aucun latest : épinglez le tag, et le digest dans un pipeline.
feint version --check ne sort sur le réseau que si vous le demandez, et ne met jamais à jour tout seul.

Prochaines étapes

Brancher les CLI officiels scw, octl et exo, le stockage bloc et la séquence d'image dorée.

Terraform contre feint Appliquer une configuration sur Scaleway et Outscale émulés.

Machines réelles et SSH Les quatre modes, Incus et OVN, et la session SSH.

Diagnostiquer une exécution feint doctor : vérifier que la station livre ce que vos tests demandent.