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.

Acceptance criteria — completed 2026-09-26 (America/Los_Angeles)

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

Completion evidence — 2026-09-26 (America/Los_Angeles)

PR #208 merged as 1111f7982e492c60abb4897844a02e7b3a44cef7 after all 28 checks passed. It records the completed publication and maintainer-readiness status, superseding the historical pending status above.

• Directly verified: Jim's Portal account has the verified org.owasp.encoder namespace. Deployment ce91e36f-756c-489f-bbea-3629b728ad28 reached PUBLISHED. The original bundle SHA-256 is c70234d2290fff0011d484219b7bc8fae2581cf24b24b03abf5eab4413b6d4c3; no artifact was rebuilt, re-signed, replaced, or retagged.
• Directly verified: all four libraries' binary/source/Javadoc JARs, all five POMs, and their 17 signatures downloaded from Central matched the retained signed release byte for byte (34 files total). Original signatures and signed checksum manifests were verified before upload.
• Maintainer confirmation: Jim confirmed that he and Jeremy both completed their independent vault-recovery drills, namespace-access checks, and separate validated-and-dropped staging rehearsals on September 26. Individual private recovery records and rehearsal deployment IDs were not supplied or independently inspected in this session; this is recorded as reported completion.
• Documentation/destinations: PR Record 1.4.1 Central publication and maintainer readiness #208 reconciles repository pending notices and ESAPI guidance; the GitHub release notice confirms Central availability. The OWASP page references 1.4.1. Javadoc indexing still showed 1.4.0 immediately after publication, a propagation follow-up rather than a Central availability failure. Recovery/failure procedures and the 1.5 release gate are retained.

Publication verification · Dated maintainer record