ci: publish docs from 4.18.1.x with the default branch's workflow - #1141

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

Walkthrough

The documentation publishing workflow was replaced. The new workflow builds documentation, checks Javadoc output, deploys to GitHub Pages, and reports missing build or API output.

Security Blast Radius

• inferred — The intended privileged outcome is replacement of this repository's published documentation, including all versions in the generated tree. A compromised writer could potentially affect other repository contents permitted by contents: write, not only gh-pages; actual reach depends on branch rules and effective token policy. The inspected path does not establish cross-repository or production-service authority.

Trust Boundaries and Controls

• inferred — There is no direct pull-request trigger. Commit-pinned actions, default-branch checkout, disabled credential persistence, and fixed origin version inputs constrain the path. Nevertheless, executable build inputs and later token-bearing deployment share a runner. Compromise of a selected build ref or dependency could persist into deployment; who can alter those inputs or execute modified workflow definitions is not established by the supplied runtime evidence. This is a conditional trust-boundary exposure, not a verified unprivileged exploit or a proven increase over effective base permissions.

Resilience and Maintainability Implications

• observed — The new validation adds a total-loss containment control and visible partial-loss reporting. It does not make publication transactional. The force-push replacement mechanism and lack of an in-workflow restoration path already existed, so they are architecture facts rather than newly introduced security findings.

Hardening Proposals

• proposed — Confirm protection of workflow definitions and selected build branches, dispatch eligibility, and effective token restrictions. If stronger build-compromise containment is required, separate uncredentialed builds from a fresh deployment job with write authority and a defined artifact handoff.
• proposed — If recovery from an authorized but incorrect publication is a requirement, retain a known-good publication snapshot and define restoration independently of the canceled or failed workflow's final status.

• X
• Mastodon
• Reddit
• LinkedIn