[Infra] Pin cosign.pub verification to initial commit hash#25273
[Infra] Pin cosign.pub verification to initial commit hash#25273yuneng-berri merged 2 commits intomainfrom
Conversation
Pin all cosign public key references to the immutable commit hash (0112e53) that first introduced the key, instead of fetching it from the release tag. This addresses the concern that an attacker with push access could replace the key on main/tags and re-sign tampered images. Docs now show two verification methods: commit hash (recommended) and release tag (convenience), with explanation of why the hash is stronger. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Greptile SummaryThis PR hardens cosign image verification by pinning the public key URL to an immutable commit hash (
Confidence Score: 5/5Safe to merge — documentation-only security improvement with no functional code changes All 6 files are updated consistently with the same immutable commit hash. No logic errors, security regressions, or breaking changes. The commit hash is correct and uniform across all locations. The workflow JS template literals are properly scoped. This is a clean, security-positive change. No files require special attention — all changes are straightforward documentation updates
|
| Filename | Overview |
|---|---|
| .github/workflows/create-release.yml | Release notes generator updated to include both pinned-hash (recommended) and tag-based (convenience) cosign verification blocks; JS template literals correctly use ${tag} |
| README.md | New 'Verify Docker Image Signatures' section added with both cosign verification methods and consistent commit hash pinning |
| docs/my-website/blog/ci_cd_v2_improvements/index.md | Blog post cosign section updated with pinned commit hash method and labeled tag-based convenience option |
| docs/my-website/blog/security_townhall_updates/index.md | Security townhall blog updated with both cosign verification methods and explicit trust caveat on tag-based approach |
| docs/my-website/blog/security_update_march_2026/index.md | March 2026 security update blog updated with both cosign verification methods, consistent with other docs |
| docs/my-website/docs/proxy/deploy.md | Deployment docs cosign verification section updated with pinned-hash recommended method and tag-based convenience option |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[User wants to verify\nLiteLLM Docker image] --> B{Choose verification method}
B --> C[Pinned commit hash\nRecommended]
B --> D[Release tag\nConvenience]
C --> E[--key .../0112e53.../cosign.pub]
D --> F[--key .../<release-tag>/cosign.pub]
E --> G[Cryptographically immutable\nNo trust assumptions needed]
F --> H[Relies on tag\nprotection rules]
G --> I[cosign verify image ✓]
H --> I
Reviews (2): Last reviewed commit: "Merge remote main into litellm_pin_cosig..." | Re-trigger Greptile
Summary
Issue
An external security reviewer pointed out that fetching the cosign public key from the release tag or
mainbranch is vulnerable — an attacker with push access could replace the key and re-sign tampered images.Fix
Pin all cosign.pub references to the immutable commit hash (
0112e53046018d726492c814b3644b7d376029d0) that first introduced the key. All docs now present two verification methods:Testing
Type
🚄 Infrastructure
📖 Documentation