# Suivi ciblé de l’audit du 2 octobre 2026

Lot documentaire `ARCH_SYSTEM_RECONSTRUCTION_BASELINE_V1`. Observations effectuées sur ArchASP le 2 octobre 2026, branche `arch-system-reconstruction-baseline-v1`, à partir de HEAD `14e547ce564d2a6c8b24e430225650c034e9d363`. Aucun script du dépôt ni mécanisme de démarrage/restauration n’a été exécuté. La [matrice de reconstruction](../reconstruction-baseline.md) sépare les choix futurs des observations.

## Niveaux de preuve et accès

Les fichiers présents et les unités déclarées prouvent une **configuration**, pas son exécution réussie. Les dates et entrées générées prouvent un **résultat écrit**, pas l’amorçabilité. La déclaration de l’utilisateur du **29 mai 2026** selon laquelle démarrage et restauration fonctionnaient après essai est conservée comme **essai historique déclaré**, sans valider l’état du 2 octobre.

Les huit lectures privilégiées autorisées (`sudo -n sbctl status`, `list-files`, `verify`, `btrfs subvolume list /`, `get-default /`, `snapper -c root list`, lecture de `/etc/snapper/configs/root`, `nft -nn list ruleset`) ont toutes répondu `sudo: a password is required`. Aucun mot de passe n’a été demandé. Le contrôle ultérieur nécessite un opérateur habilité ; son résultat devra être expurgé avant publication.

## AS-001 et AS-009 — carte de démarrage, signature et snapshots

Versions locales relevées par `pacman -Q` : `sbctl 0.18-2`, `mkinitcpio 42.1-1`, `limine 12.9.1-1`, `limine-snapper-sync 1.32.0-1`, `snapper 0.13.2-1`, `snap-pac 3.0.1-3`, `linux-lts 6.18.54-2`, `linux-zen 7.2.8.zen1-2`.

```text
transaction pacman : 05-snap-pac-pre.hook puis 10-limine-snapper-lock.hook
  -> snapshot pré-transaction possible ; verrou de synchronisation
  -> installation ou mise à jour du noyau
  -> hook ALPM 90-mkinitcpio-install.hook (PostTransaction, si déclenché)
  -> presets locaux : noyau + initramfs Zen/LTS dans /boot ; UKI commentés
  -> post-hook mkinitcpio /usr/lib/initcpio/post/sbctl : signe le noyau cible
     si son contrôle de clés réussit ; ne signe pas ici l'initramfs séparé
  -> zz-snap-pac-post.hook : snapshot post-transaction possible

hook ALPM zz-sbctl.hook du paquet
  -> masqué par /etc/pacman.d/hooks/zz-sbctl.hook -> /dev/null
  -> son « sign-all -g » PostTransaction ne doit pas être supposé actif

Snapper sur la racine
  -> plugin /usr/lib/snapper/plugins/10-limine-snapper-sync
  -> synchronisation asynchrone des entrées ; cleanup appelle aussi la sync
  -> /boot/limine.conf et copies d'historique de noyau/initramfs/microcode
  -> entrée normale ou entrée de snapshot sélectionnée dans Limine
```

Cette carte indique des **déclencheurs possibles**, pas une chronologie prouvée pour une transaction passée. Les hooks ALPM sont ordonnés par nom ; le fichier homonyme du répertoire prioritaire peut masquer celui du paquet par lien `/dev/null` ([alpm-hooks(5)](https://man.archlinux.org/man/alpm-hooks.5.en)). Les hooks `05-snap-pac-pre.hook` et `zz-snap-pac-post.hook` sont installés ; leurs homologues suffixés `.hook.disabled` ne sont pas des hooks actifs. `90-mkinitcpio-install.hook:34-38` invoque le helper mkinitcpio ; `/usr/bin/mkinitcpio:793-819,1240-1241` lance les post-hooks après génération sauf option contraire. `/usr/lib/initcpio/post/sbctl:6-25` choisit le noyau ou un UKI, puis appelle `sbctl sign`. Les presets `/etc/mkinitcpio.d/linux-{lts,zen}.preset` n’activent que l’image normale et commentent les UKI. L’existence du post-hook permet donc une voie de signature **du noyau**, sous conditions ; elle ne démontre ni son exécution passée, ni la signature du chargeur EFI, ni celle des copies d’historique. Le hook `zz-sbctl` masqué ne prouve pas l’absence de toute autre voie.

| Artefact utilisé ou présent | Producteur et emplacement logique | Copie, authentification et déclencheur identifiés | Ce qui reste non vérifié |
|---|---|---|---|
| EFI de repli `EFI/BOOT/BOOTX64.EFI` | Binaire PE comportant un marqueur Limine sur l’ESP ; `efibootmgr` indique cette entrée comme courante | Secure Boot est activé d’après `sbctl status` non privilégié ; fichier EFI présent, daté de mai | Signature exacte, correspondance avec le binaire démarré et mécanisme de mise à jour |
| EFI sous `EFI/arch-limine/` | Autre binaire Limine présent sur l’ESP, différent de la copie de repli ; entrée EFI nommée Arch Linux Limine existe | Aucun hook local démontré pour le signer ou le mettre à jour | Quelle entrée doit rester disponible et quels fichiers sbctl suit |
| Noyaux Zen/LTS dans `/boot` | Paquets noyau et mkinitcpio ; fichiers datés du 2 octobre | Post-hook sbctl installé et exécutable, conditionné par l’état des clés ; hook ALPM mkinitcpio présent | Exécution passée, signature actuelle et politique de vérification Limine |
| Initramfs et microcode séparés dans `/boot` | mkinitcpio et paquet microcode ; référencés par `/boot/limine.conf:18-27` | Modules Limine ; aucune signature EFI directe identifiée pour ces fichiers séparés | Intégrité effective et cohérence avec le noyau chargé |
| Copies de noyaux, initramfs et microcode pour snapshots | `limine-snapper-sync` ; chemins `limine_history/..._sha256_...` dans le menu généré | Noms avec empreinte SHA-256, déduplication/intégrité propres à l’outil selon la documentation locale | Existence et contrôle de **toutes** les copies, lien avec la chaîne Secure Boot, capacité à démarrer |
| `limine.conf` et métadonnées de snapshots | Synchronisation Snapper/Limine ; `/boot/limine.conf` généré le 2 octobre | Section « Auto-generated » présente ; le modèle versionné garde seulement la partie non générée | Correspondance exacte entre menu, snapshots et fichiers, restauration réelle |

`efibootmgr` montre l’entrée courante `UEFI OS` vers le chemin de repli et une entrée `Arch Linux Limine` distincte. `/boot/limine.conf:12` définit une entrée par défaut et les lignes 14–27 référencent Zen et LTS avec noyau et modules séparés ; aucun UKI actif n’a été observé dans les presets. Le nom `_sha256_` d’une copie historique n’est pas une preuve de signature EFI. Un futur `sbctl verify` vérifierait les fichiers qu’il examine, pas la totalité des dépendances d’une entrée ni un démarrage réel ([sbctl(8)](https://man.archlinux.org/man/sbctl.8.en)).

Pour la synchronisation, le service `limine-snapper-sync.service` est désactivé/inactif ; ce n’est **pas** une preuve d’absence de synchronisation. Le plugin Snapper installé agit seulement sur le sous-volume `/` et lance la sync de façon asynchrone (`/usr/lib/snapper/plugins/10-limine-snapper-sync:17-18,64-102`). `snapper-cleanup.service.d/limine-snapper-override.conf:4` invoque aussi la sync après cleanup. Le journal des changements local de l’outil indique que l’observateur est optionnel depuis sa version 1.16.0. Les timers cleanup/timeline sont activés ; la configuration Snapper réellement chargée n’a pas été lue.

La configuration du dépôt et celle lisible sous `/etc/limine-snapper-sync.conf` concordent : racine `@`, snapshots `@/.snapshots`, `RESTORE_METHOD=replace`, `SET_SNAPSHOT_AS_DEFAULT=no` (`rootfs/etc/limine-snapper-sync.conf:110-181`). Pour la version installée, la documentation locale décrit `replace` comme la création d’un nouveau sous-volume depuis le snapshot sélectionné, remplaçant l’ancien sous-volume racine ; l’ID de sous-volume change et la relation avec les anciens snapshots n’est plus suivie comme avec `snapper rollback`. Les montages séparés `@home`, `@log` et `@pkg` ne font pas partie du sous-volume racine `@` observé ; leur contenu ne doit pas être présumé restauré par cette opération. L’effet exact sur ce poste, le sous-volume Btrfs par défaut et le retour à l’état normal restent à éprouver. Le snapshot local ne protège pas de la perte du SSD.

**Conclusion proportionnée :** AS-001 reste **ouvert** : hook pacman masqué confirmé, post-hook de signature du noyau confirmé, signatures et politique complète non vérifiées. AS-009 reste **ouvert** : voies de synchronisation et entrées de snapshots confirmées, démarrage/restauration actuels non vérifiés. La raison du masquage n’apparaît pas dans les documents actifs ni dans les commits ciblés du dépôt ; elle ne peut être inventée. Aucun hook n’a été réactivé.

## Compléments ciblés AS-002 à AS-008

| ID | Réévaluation au 2026-10-02 | Preuve et suite |
|---|---|---|
| AS-002 | **Confirmé, ouvert.** Le premier démarrage n’est toujours pas une procédure complète. | `docs/reinstall.md:29-67` énumère Limine, Snapper et sbctl sans séquence testée. Ajouter la procédure seulement après décisions sur signature, réseau et disponibilité des copies. |
| AS-003 | **Confirmé, ouvert.** `yay` est installé sur ArchASP mais absent de l’ISO et non amorcé par `deploy.sh`. | `pkglist/aur.txt:12`, `scripts/deploy.sh:171-180`. Le noyau et le premier démarrage relèvent du socle ; l’intégration AUR/Snapper suit. Futur amorçage : outil de construction et dépendances disponibles, source et révision vérifiées, identité de l’utilisateur de construction, résultat installé et reproductible. Aucune construction ici. |
| AS-004 | **Confirmé pour les fichiers ; exécution non vérifiée.** Le dépôt cible `wg0`, `/etc/nftables.conf` cible `wlp1s0` pour DNS, Web, trafic des VM et NAT. `wg-quick@wg0` est en échec. | Comparaison ciblée des deux fichiers ; `systemctl show`. L’un ou l’autre fichier peut changer l’accès du poste et des VM. `nftables.service` inactif n’indique pas le contenu des règles effectives. `sudo -n nft -nn list ruleset` refusé ; politique VPN/flux encore à décider. |
| AS-005 | **Risque conditionnel inchangé.** Script destructif avec confirmation et contrôle des montages, mais sans preuve générale sur tous les usages actifs du disque ou sur une reprise après échec. | `scripts/prepare-disk.sh:15-69`. Renforcement et essais sur disques de test dans un lot ultérieur ; aucun script exécuté ici. |
| AS-006 | **Confirmé, nuancé.** Btrfs/EFI de base conforme. Zram 6 Gio coexiste avec un swapfile 8 Gio, déclaré dans `/etc/fstab`, et un swap de 64 Gio sur périphérique ; `/etc/fstab` mentionne aussi un espace de travail et des swaps avec `nofail`. | `findmnt`, `swapon --show`, `/etc/fstab:18-25` expurgé. Le swapfile est configuré pour persister ; le périphérique est actif mais sa pérennité et son besoin restent à décider. Le nom `/swap-colmap` ne prouve pas un usage temporaire. |
| AS-007 | **Confirmé, à qualifier.** CUPS service/socket/path activés et actifs, cohérent avec une disponibilité après démarrage ; `hplip`, `sane`, `sane-airscan` explicites. nginx activé/actif, configuration locale en boucle locale servant Trainlog ; Avahi service/socket activés/actifs, utilité exacte non établie. VMware/Samba demeurent désactivés/inactifs à la demande ; WireGuard est en échec. | `systemctl list-unit-files`, `list-units`, `pacman -Qi`, `/etc/nginx/nginx.conf:22-37`. Les unités utilisateur et données Trainlog restent hors dépôt. Tester impression, scan et proxy avant de modifier le manifest. |
| AS-008 | **Confirmé.** `backup.sh` exporte listes explicites, inventaires, fichiers système sélectionnés et modèle Limine ; il n’exporte pas les scripts utilisateur. `deploy.sh` tolère certaines sources absentes et peut laisser un état partiel. | `scripts/backup.sh:19-221`, `scripts/deploy.sh:74-99,184-289`. Corriger maintenant seulement la documentation ; revoir le diff et les données sensibles avant toute publication ; scripts et tests isolés dans un lot ultérieur. |

`pacman -Qqen`/`-Qqem` donnent respectivement 251/17 noms contre 216/12 dans les exports de juillet. `opencode` et `openai-codex-desktop` sont **absents des paquets installés au relevé**, bien qu’encore listés ; `colmap` et plusieurs paquets `-debug` sont présents parmi les étrangers. `hplip`, `sane`, `sane-airscan`, `nginx`, `rclone` et `smartmontools` sont des installations natives explicites récentes à qualifier par fonction, sans import global dans `pkglist/`. Les bases de synchronisation locales sont datées des 1er–2 octobre ; `-Qm`/`-Qn` classent par rapport à ces bases et ne prouvent pas l’origine AUR ou officielle dans tous les cas ([pacman(8)](https://man.archlinux.org/man/pacman.8.en)).

## Travaux suivants et preuve de fermeture

1. **Arbitrer les points ouverts de la matrice** : déverrouille une cible de reconstruction explicite. Preuve : décisions datées sur signature, réseau, fonctions du poste, swaps et copies indépendantes.
2. **Rédiger la procédure complète de réinstallation** : déverrouille un parcours depuis le support live jusqu’au premier démarrage, puis au retour des fonctions. Preuve : essai sur installation de test avec critères d’arrêt et de reprise.
3. **Renforcer les scripts et les valider en isolement** : déverrouille une exécution moins fragile des étapes destructives et du déploiement. Preuve : tests de panne, reprises et diff d’export contrôlé, sans disque de production.
4. **Essayer démarrage et restauration de façon contrôlée** : déverrouille une conclusion opérationnelle limitée à la version testée. Preuve : vérification autorisée des signatures, snapshots et règles, démarrage normal et de secours, restauration ciblée et retour normal.