shankar0123 320ef7344e fix(deploy/test/libest): pin LIBEST_REF to upstream tag r3.2.0 ...

The Dockerfile at HEAD pinned LIBEST_REF=v3.2.0-2 — that ref does
NOT exist on cisco/libest upstream. Verified via:

    curl -sS https://api.github.com/repos/cisco/libest/tags
    # only tags returned: v1.0.0, r3.2.0, 1.1.0

The 'v' prefix and the '-2' patch suffix were both wrong from day
one (commit 15da1f4, EST RFC 7030 hardening Phase 10.1). The bug
went undetected because the libest sidecar Dockerfile was never
built end-to-end — neither operator-side nor in CI. The Dockerfile's
own header comment ('last tag 3.2.0-2 from 2018') was inaccurate
in the same way.

This fix:
  - ARG LIBEST_REF=v3.2.0-2 → r3.2.0 (the actual upstream tag, sha
    4ca02c6d7540f2b1bcea278a4fbe373daac7103b verified via
    api.github.com/repos/cisco/libest/git/refs/tags/r3.2.0)
  - Updated the surrounding head-comment block to reflect the real
    upstream tag name + cite the 2026-04-30 GitHub API verification.
  - Added a note explaining the prior broken pin so future readers
    don't re-introduce it.

The estclient binary built from r3.2.0 supports the only RFC 7030
endpoint the est_e2e_test.go exercises ('estclient -g' = GET
cacerts), so the integration test still works against this ref.

Closes the libest-build-failure surfaced by ci-pipeline-cleanup
Phase 8's Docker build smoke step (CI run 25192163943, job
'image-and-supply-chain').

2026-04-30 22:38:27 +00:00

..

Dockerfile

fix(deploy/test/libest): pin LIBEST_REF to upstream tag r3.2.0

2026-04-30 22:38:27 +00:00