Complete release readiness: Central 1.4.1 publication and independent maintainer recovery

[jmanico]

Reviewed 2026-09-25 (America/Los_Angeles) against main at bd249f5. Execution order and cross-issue ownership: #169. Batch 00.

This scope replaces the dated implementation prescriptions in the original report and earlier comments; linked historical evidence remains useful but must be rechecked before implementation.

Current state

PRs #156 and #164 added RELEASING.md, MAINTAINERS.md, the project signing key, recovery instructions, and the README release link. Those documentation tasks are complete. GitHub has the signed 1.4.1 security release; a live check still finds Central's encoder/1.4.1/encoder-1.4.1.pom returning 404 and metadata listing 1.4.0. MAINTAINERS.md records unconfirmed individual vault drills and publishing access/rehearsals. Continue the existing Central Support request; do not open another.

Remaining acceptance criteria

• Restore/confirm namespace publishing access for the designated publishers, independently of signing-key custody. Record status without tokens or private material.
• When access is available, publish the retained exact signed 1.4.1 bundle under the existing release procedure. Do not rebuild it, change signatures, replace artifacts, or move the tag. Verify all four libraries and the parent POM on Central against retained checksums/signatures; record evidence.
• Only after verification, reconcile Central-pending notices in README, SECURITY.md, the release notes and GitHub release. Clarify ESAPI dependency policy by release and preserve the 1.4.1 upgrade warning #112 owns ESAPI consumer guidance.
• Each custodian independently confirms retrieval from their own vault and completes the documented isolated recovery drill. A local backup test is not evidence for either vault.
• Each publisher confirms their own namespace access and validated-then-dropped staging rehearsal. Use a nonpublished rehearsal version/bundle; never republish 1.4.1. Record only nonsecret evidence in the dated maintainer status.
• Check recovery/failure procedures and post-release destinations against the actual results; retain the 1.5 backlog gate in RELEASING.md.

This is the single owner for operational custody, access and rehearsal work previously repeated in #95. #95 retains future release-tooling modernization; it is not a prerequisite to uploading the existing bundle. This organization pass does not itself publish anything.

Batch 00 evidence — 2026-09-25 (America/Los_Angeles)

#171 merged as 6a3c3a9bd5d8eaa82c6ee956ab78ff9e11821b6f, recording the dated results and clarifying exact-bundle retry/comparison requirements and distinct nonpublished rehearsal versions. All 20 PR checks passed. The operational acceptance criteria below remain open. All five 1.4.1 POMs returned HTTP 404 from Central at 2026-09-26 04:48:36 UTC. Jim's current signed-in Portal account showed No Namespace(s) Found and disabled Publish Component. Namespace access therefore still blocks publication and his rehearsal; Jeremy's access remains unconfirmed. Continue the existing Support request; no new request or deployment was created.

Jim confirmed initial key setup today, not retrieval and a drill from his own vault or a validated-and-dropped staging rehearsal. No independent confirmation was received from Jeremy. Keep those acceptance criteria open.

The retained GitHub bundle was downloaded and verified without alteration: 19 project-key signatures, both signed checksum manifests, all 17 bundled JARs/POMs and their matching standalone signatures, and all bundled MD5/SHA-1/SHA-256/SHA-512 checksums. SHA-256: c70234d2290fff0011d484219b7bc8fae2581cf24b24b03abf5eab4413b6d4c3. Public artifact verification does not establish private-key recovery or publishing access. The OWASP project page still recommends 1.3.0; javadoc.io identifies 1.4.0. Reconcile these destinations with actual release availability as part of the follow-up.

Detailed evidence. Central-pending notices and the 1.5 backlog gate remain in force; this issue remains open.