Issue Station
Sign In
Tools hereToolbox

litellm - ✅(Solved) Fix Request: cosign image signatures and SLSA provenance attestations for GHCR images [1 pull requests, 5 comments, 5 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#24524•Fetched 2026-04-08 01:22:48
View on GitHub
Comments
5
Participants
5
Timeline
11
Reactions
12
Author
markshields-tlmarkshields-tl
Participants
DanielRufDanielRufishaan-berriishaan-berrikrrish-berri-2krrish-berri-2markshields-tlmarkshields-tlqurczakqurczak
Timeline (top)
commented ×5cross-referenced ×2mentioned ×2subscribed ×2

Please add cosign signatures and SLSA provenance attestations to the container images published to GHCR (ghcr.io/berriai/litellm, ghcr.io/berriai/litellm-database).

Root Cause

Please add cosign signatures and SLSA provenance attestations to the container images published to GHCR (ghcr.io/berriai/litellm, ghcr.io/berriai/litellm-database).

Fix Action

Fixed

PR fix notes

PR #24543: fix(security): migrate PyPI publishing to Trusted Publishers (OIDC)

Description (problem / solution / changelog)

Summary

Closes #24542

Migrates all three PyPI publishing workflows from stored API tokens (PYPI_PUBLISH_PASSWORD / PYPI_ENTERPRISE) to PyPI Trusted Publishers (OIDC-based authentication).

This eliminates the attack vector used in the March 24 incident — there is no longer a stored token that can be stolen and used to publish malicious packages.

Changes

  • simple_pypi_publish.yml (main litellm package):

    • Removed TWINE_USERNAME env and TWINE_PASSWORD secret reference
    • Removed twine from installed dependencies
    • Added top-level permissions: id-token: write, contents: read
    • Added environment: pypi for deployment protection rules
    • Replaced twine upload step with pypa/gh-action-pypi-publish@release/v1

  • publish_enterprise.yml (litellm-enterprise package):

    • Added id-token: write to job permissions
    • Added environment: pypi-enterprise
    • Replaced twine upload with pypa/gh-action-pypi-publish@release/v1 (with packages-dir: enterprise/dist/)

  • publish_proxy_extras.yml (litellm-proxy-extras package):

    • Added id-token: write to job permissions
    • Added environment: pypi-proxy-extras
    • Replaced twine upload with pypa/gh-action-pypi-publish@release/v1 (with packages-dir: litellm-proxy-extras/dist/)

All existing build, version update, and non-publish steps are unchanged.

Admin Setup Required

Before merging, a PyPI project admin needs to configure Trusted Publishers on pypi.org. For each package:

  1. Go to pypi.org → the package → Publishing → Add a new publisher
  2. Configure the trusted publisher:
PackageWorkflowEnvironment
litellmsimple_pypi_publish.ymlpypi
litellm-enterprisepublish_enterprise.ymlpypi-enterprise
litellm-proxy-extraspublish_proxy_extras.ymlpypi-proxy-extras
  1. Create the corresponding GitHub environments (pypi, pypi-enterprise, pypi-proxy-extras) in repo Settings → Environments
  2. After verifying Trusted Publishers work, delete the PYPI_PUBLISH_PASSWORD and PYPI_ENTERPRISE secrets from GitHub repo settings

How It Works

Instead of authenticating with a stored API token, the workflow:

  1. Requests a short-lived OIDC token from GitHub (via id-token: write permission)
  2. Sends the OIDC token to PyPI
  3. PyPI verifies the token was issued by GitHub for the correct repo/workflow/environment
  4. PyPI authorizes the publish — no stored secret involved

References

Changed files

  • .github/workflows/publish_enterprise.yml (modified, +6/-6)
  • .github/workflows/publish_proxy_extras.yml (modified, +6/-6)
  • .github/workflows/simple_pypi_publish.yml (modified, +14/-14)

Code Example

- uses: sigstore/cosign-installer@v3
   - run: cosign sign --yes ghcr.io/berriai/litellm-database@${{ steps.build.outputs.digest }}
RAW_BUFFERClick to expand / collapse

Summary

Please add cosign signatures and SLSA provenance attestations to the container images published to GHCR (ghcr.io/berriai/litellm, ghcr.io/berriai/litellm-database).

Motivation

The 2026-03 PyPI supply chain attack targeting litellm highlights the importance of verifiable supply chain integrity across all distribution channels — not just PyPI but also container images.

Currently, the GHCR images have no cosign signatures and no SLSA attestations (verified via cosign tree on multiple tags including main-v1.82.0-stable and main-latest). This means consumers cannot cryptographically verify that:

  1. An image was built by BerriAI's CI (not a compromised actor)
  2. An image corresponds to a specific source commit
  3. An image hasn't been tampered with post-build

What we're asking for

  1. Cosign keyless signing in CI — signs images with the GitHub Actions OIDC identity. One line in the release workflow:

    - uses: sigstore/cosign-installer@v3
- run: cosign sign --yes ghcr.io/berriai/litellm-database@${{ steps.build.outputs.digest }}

  2. SLSA provenance (optional but ideal) via slsa-framework/slsa-github-generator for Level 3 build provenance.

Both are free, use GitHub's built-in OIDC, and require no key management.

Impact

This would allow consumers to enforce admission policies (e.g., via Kyverno, OPA Gatekeeper, or Sigstore policy-controller) that reject unsigned images — a standard supply chain security control that's currently impossible with LiteLLM's container distribution.

Given the PyPI incident, this seems like a timely hardening step for the container side of the distribution pipeline.

Thank you!

extent analysis

Fix Plan

To address the issue, we will implement cosign keyless signing and SLSA provenance for the container images published to GHCR. Here are the steps:

Cosign Keyless Signing

  1. Install cosign: Add the following line to the release workflow:
  • uses: sigstore/cosign-installer@v3
2. **Sign images**: Add the following line to the release workflow:
   ```yaml
- run: cosign sign --yes ghcr.io/berriai/litellm@${{ steps.build.outputs.digest }}
- run: cosign sign --yes ghcr.io/berriai/litellm-database@${{ steps.build.outputs.digest }}

SLSA Provenance (optional)

  1. Install slsa-github-generator: Add the following line to the release workflow:
  • uses: slsa-framework/slsa-github-generator@v1
2. **Generate provenance**: Add the following line to the release workflow:
   ```yaml
- run: slsa-github-generator --github-token ${{ secrets.GITHUB_TOKEN }} --github-repo berriai/litellm --github-ref ${{ github.sha }} --artifact-path ghcr.io/berriai/litellm:latest
- run: slsa-github-generator --github-token ${{ secrets.GITHUB_TOKEN }} --github-repo berriai/litellm --github-ref ${{ github.sha }} --artifact-path ghcr.io/berriai/litellm-database:latest

Verification

To verify that the fix worked, run the following command:

cosign verify ghcr.io/berriai/litellm:latest
cosign verify ghcr.io/berriai/litellm-database:latest

This should display the verification result, indicating that the images are signed with the GitHub Actions OIDC identity.

Extra Tips

  • Make sure to store the GitHub token as a secret in the repository settings to avoid exposing it in the workflow file.
  • Consider implementing admission policies using tools like Kyverno, OPA Gatekeeper, or Sigstore policy-controller to enforce the use of signed images.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#parallel task#integration issue#index setup#retrieval issue#search optimization

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING