0.7.0 release checklist: two missing tests, three stale documents, one decision

[guimard]

Everything below is verified against main at the time of writing, and is what
stands between the current tree and a defensible 0.7.0 tag. Ordered by what
changes the security claim, not by effort.

1. find_anchor() has two implementations and no test

src/ob-fp-daemon.c:250 and src/pam_openbastion.c:1774 implement the same
walk, and the daemon's own comment says:

This MUST agree exactly with pam_openbastion's find_sshd_session_ancestor(),
or the module looks for a drop under a key this daemon never wrote.

Nothing verifies that sentence: grep -rl 'find_anchor\|find_sshd_session_ancestor' tests/
returns nothing. A divergence breaks the SSH fingerprint binding silently —
no error at login, the module simply finds no drop — and that binding is what
doc/security/99-risk-reduce.md credits with reducing R-S3 and R-S15.

This is the same class of drift that #254 removed for the systemd units, left
in place on the mechanism whose trust root #249 had just moved.

Acceptance: one test drives both implementations over the same synthetic
/proc ancestry and requires identical output, including the edge cases the
walk defines (depth limit, non-contiguous sshd-session, pid 1). It goes in
tests/mutation/catalogue afterwards, so a future divergence fails rather than
being noticed by reading.

2. src/cache_key.c rejection branches have no test

4cbe85c added them and touched no test file; there is no tests/test_cache_key*.
Six rejected paths are uncovered: not a regular file, not root-owned,
setuid/setgid bits, and group/other permission bits.

It is the only hardening of the 0.7.0 series with no proof, and it corrects a
real branch-nesting bug.

Acceptance: unit tests for each refusal, and a catalogue entry so removing
one fails.

3. Documentation that contradicts the tree

Small, no design decisions, and an evaluator reads these before reading code:

• CMakeLists.txt:2 still says VERSION 0.6.2.
• doc/security/07-plan-de-traitement.md: MT52 is marked Ouvert although
  The PAM client signs 2 of 6 /pam/* endpoints, so pamAccessRequestSigningMode=required cannot be turned on #247 and feat(pam): sign every /pam/ call, so pamAccessRequestSigningMode=required becomes deployable #252 are merged.
• SECURITY.md:539 still lists "Encrypted secrets in the secret store become
  permanently unrecoverable" among the impacts of a machine-id change. The main
  passage was corrected when the store was removed; this bullet in the
  machine-id section was not.

4. A process note in the homologation dossier

Not a defect, a gap in the record. 113 of the 166 commits since v0.6.2 carry a
Claude-Session trailer and 160 are dated across three days. Both are accurate:
this was an AI-assisted campaign with human review at each merge, and the
reviews are recorded on the pull requests.

History will not be rewritten — the SHAs are cited in 99-risk-reduce.md and
in issues, so rewriting would break the traceability it would be meant to
protect. The right answer is therefore to state what happened, in
doc/security/08-dossier-homologation.md alongside the trust assumptions, so an
evaluator's first question ("36 PRs in three days — who reviewed them?") has a
verifiable answer instead of an absence.

5. Decide R-P1 — the actual release gate

The only item here that changes what the product claims.

With pamAccessServerGroups empty — the multi-group configuration the
architecture document recommends — any compromised enrolled host can declare
itself a bastion and obtain vouchers. The upstream fix is merged and unreleased;
allowed_bastions empty still means "accept any" by default, for Ansible
compatibility.

It is documented and assumed, but it is the shipped default. Two honest
positions:

• make the published plugins and pamAccessAllowedRps a documented release
  prerequisite; or
• accept R-P1 explicitly as a residual risk in the dossier, with the acceptance
  signed.

Anything between the two is what an evaluator will find first.

---

Not blocking, and tracked separately: #262 (no test covers the 0.6.0 portal
generation, waiting on a published image).

Raised by a global review of v0.6.2..HEAD; items 1–3 verified against the tree
before filing.

[guimard]

Quatre PR, dans l'ordre des points.

Point	PR
1. find_anchor() en double	#269	une seule implémentation, src/sshd_anchor.c, + 14 assertions sur un /proc synthétique
2. cache_key.c sans test	#270	16 assertions ; a fait apparaître un défaut réel (voir plus bas)
3. Documents contredisant l'arbre	#271	SECURITY.md, MT52 — et MT51, même péremption
4. Note de procédure au dossier	—	laissé ouvert, à ta main
5. Décision R-P1	#272	prérequis de publication

Trois écarts par rapport à l'énoncé, tous délibérés :

Point 1 — unifié plutôt que testé en double. L'énoncé demandait un test qui
pilote les deux implémentations et exige un résultat identique. Il n'y en a
plus qu'une : les deux copies étaient déjà équivalentes (je l'ai vérifié avant
de les fusionner — seuls les gardes de boucle divergeaient, sans effet sur le
résultat), et supprimer la possibilité même de la dérive vaut mieux que la
détecter. Le test conserve la propriété qui compte : la profondeur de
l'écrivain et celle du lecteur, dans le même arbre, donnent le même pid.

Point 2 — un défaut, pas seulement un manque de test. read_key_file()
ouvrait en O_RDONLY|O_NOFOLLOW, et l'ouverture d'un fifo en lecture seule
bloque jusqu'à ce qu'un écrivain se présente : le refus « pas un fichier
régulier » juste en dessous était inatteignable, et un fifo à
/etc/open-bastion/cache.key garait l'appelant indéfiniment — sur le chemin
PAM, une connexion qui ne finit jamais. Poser ce fifo demande le droit
d'écriture dans /etc/open-bastion, donc aucune frontière de privilège n'est
franchie : c'est un contrôle qui ne pouvait pas se déclencher. O_NONBLOCK le
rend atteignable.

Il fallait aussi rendre les quatre refus situés sous le test de propriété
atteignables sans root, sinon ils restaient non couverts dans tout job CI non
privilégié — et une suite qui saute ne prouve rien.

Point 5 — le produit prévient, il ne vérifie pas. pamAccessServerGroups et
pamAccessAllowedRps sont des réglages du Manager : les interroger depuis un
hôte supposerait une API qui publierait les bastions, groupes et RP du projet.
La consigne est donc imprimée par les quatre scripts (ob-*-setup et
ob-post-upgrade) et ob-builder écrit une PORTAL-CHECKLIST.md pré-remplie
à côté de chaque artefact — surtout utile pour le rôle Ansible, dont personne
ne lit la sortie de la tâche.

Effet de bord assumé : trois documents d'exploitation recommandaient de laisser
pamAccessServerGroups vide, ce qui est exactement la configuration
exploitable. Ils disent maintenant l'inverse, avec le prix à payer — un
client_id par groupe de serveurs, un client_id non mappé étant refusé.

tests/mutation/catalogue n'existait pas quand l'issue a été écrite ; il
existe depuis #267, et les dix nouvelles entrées y sont (catalogue à 14/14, plus
les cinq de #270 vérifiées sur leur branche).

Reste ouvert : le point 4, et CMakeLists.txt:2 (bump de version, à la
release). J'ai aussi laissé en l'état, faute de pouvoir le vérifier, la puce
« Server enrollment tokens must be re-issued » de la section machine-id : rien
dans ce dépôt ne lie un jeton d'enrôlement à /etc/machine-id, mais l'identité
machine est frappée en amont.