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é.

Prérequis : un terminal Linux ou macOS. Selon le chemin choisi, il vous faut en plus curl, sha256sum et cosign (release vérifiée), Docker ou Podman (image de conteneur), ou Homebrew ou mise (les deux autres canaux). Les machines réelles de Feint demandent un hôte Linux avec Incus, le gestionnaire de conteneurs système et de machines virtuelles dont le tableau ci-dessous parle, installé comme l'explique le guide d'installation d'Incus.

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

Glissez pour voir

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 canaux 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. La signature repose sur Sigstore, un service public de signature, et se vérifie avec cosign, son outil en ligne de commande.

Canal	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

Glissez pour voir

Release vérifiée

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.

1. 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"

2. Vérifier la signature de la liste de sommes, avant de faire confiance à une seule ligne de son contenu.

   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.

3. Vérifier les octets contre la liste signée.

   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.

4. Installer le binaire et confirmer la version.

   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

Cette commande peut sembler muette

Hors terminal interactif, dans un script ou un pipeline de CI, gh attestation verify n'affiche rien et se contente de son code retour. Fiez-vous à echo $?, qui doit valoir 0, ou ajoutez --format json pour obtenir le détail. Un silence n'est pas un échec ici.

Homebrew

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.

mise

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.

GitHub Actions

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.

GitLab CI

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

Action GitHub

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

Un tag par version, et rien de mutable

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é.

Couper la vérification dans un environnement fermé

FEINT_NO_UPDATE_CHECK=1 refuse la vérification, même si le drapeau est tapé : la commande affiche la version, puis update check disabled by FEINT_NO_UPDATE_CHECK, et aucune requête ne sort. C'est le réglage à poser sur un runner de CI ou un poste sans accès Internet. Sans le drapeau, feint version seul n'a jamais contacté quoi que ce soit.

À 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.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →