[codex] release v2.4.0 hardening

[IgnazioDS]

Summary

This PR completes the SentinelID v2.4.0 release-hardening work needed to eliminate version drift, tighten production secret storage, reduce CORS surface area, and remove .env interpolation footguns from the release path.

Problem

Several release-critical version sources were out of sync, including the cloud API metadata, which meant the release gate could pass while operator docs, packaged desktop metadata, and reported service metadata drifted apart. On the edge side, production key material could silently fall back to filesystem storage when the OS keychain was unavailable, which weakens the intended secret-storage posture. The edge API also allowed wildcard CORS methods and headers, which was broader than the desktop/admin clients actually need. Finally, bcrypt hashes copied into .env could trigger Docker Compose interpolation warnings because of unescaped $ characters, and older phase-era documentation could still distract operators from the current runbook/release path.

Fix

The release line is now advanced to v2.4.0 across the maintained docs, Make help banner, desktop package metadata, pilot evidence targets, and the cloud FastAPI version string. The version consistency script now validates the packaging guide, recovery guide, pilot freeze guide, and cloud metadata in addition to the previous files. The release checklist also runs a new .env secret interpolation linter that fails early when secret values contain unsafe $ sequences.

For edge secret storage, device keypair and master-key initialization now refuse filesystem/non-keychain fallback in EDGE_ENV=prod unless ALLOW_KEYCHAIN_FALLBACK=1 is explicitly set for controlled debugging. For CORS, the wildcard method/header allowances were replaced with the explicit methods and headers needed by the desktop and admin clients. The admin server env loader was updated to tolerate quoted values so quoted bcrypt hashes remain usable, and the outdated docs/phase8_verification.md document was removed.

Validation

I ran focused edge regression tests for the new keychain fallback guards and CORS behavior, then ran the full release gate successfully with make release-check. I also confirmed the version-consistency failure mode by temporarily misaligning the cloud version and verifying that make release-check stopped at the version check. docker compose build cloud admin completed without bcrypt interpolation warnings after quoting the local .env bcrypt hash. Finally, I validated the strict tag-alignment path by running RELEASE_EXPECT_TAG=v2.4.0 make release-check against a temporary local v2.4.0 tag pointing at HEAD, then removing that temporary tag so no misleading release tag remained in the local repo.

[chatgpt-codex-connector]

💡 Codex Review

SentinelID/apps/edge/sentinelid_edge/services/security/keychain.py

Lines 73 to 77 in f65768c

	stored_in_keychain = self._store_to_os_keychain(keys)
	if stored_in_keychain:
	self._delete_file_copy()
	else:
	self._store_to_file(keys)

Guard prod fallback before writing generated keypair to file

In load_or_generate, the new production guard only runs when _os_keychain_available() fails, but the generated-key path still writes device_keys.json whenever _store_to_os_keychain() returns False. That means EDGE_ENV=prod can still silently fall back to filesystem storage (without ALLOW_KEYCHAIN_FALLBACK=1) if the backend allows get_password but fails on set_password (for example due to locked/permission-limited keychain), which bypasses the hardening guarantee for device private key storage.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".