arch-system/docs/audits/2026-10-02-followup.md

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

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

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

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.