:focal(smart))
A Sigstore attestation will tie the producer of a package (for example a GitHub Actions workflow) to the package artifact uploaded on prefix.dev – thanks to Trusted Publishing, this is smooth and verifiable.
When the attestation is created, metadata about the artifact is registered in a "Transparency Log" which we can inspect at all times. The metadata contains information such as:
The name of the package
The SHA256 hash of the package data (you can use this to find the log entry!)
The CI workflow that built the package
The repository Git hash that contained the CI workflow
The organization and the username that built the package
Thus, using this information we can attest that a given package was created and uploaded by a certain GitHub organization, and this is transparently logged on our server and the Sigstore public good instance.
Part of the attestation is also a "predicate" that collects facts about the artifact that is signed. We went through a lengthy process together with the Conda community to design this predicate – with the help of Trail of Bits (thank you, William Woodruff and Facundo Tuesca!) – which resulted in CEP-27 which provides all the technical details.
The in-toto attestation with the v1 Conda predicate contains the following facts about the package:
The SHA256 hash of the package (guaranteed to be unique)
The full filename ({name}-{version}-{buildstring}.conda)
Optionally, the predicate, which contains the full URL to the target channel, for example: https://prefix.dev/my-channel (the channel URL is defined as the place where you would attach noarch/repodata.json).
Since this post was first published, signing has moved directly into the build tools. You no longer need to wire up actions/attest yourself. Both pixi and rattler-build can mint the attestation and upload it alongside the package in a single step, with --generate-attestation.
Combined with Trusted Publishing, that means no API keys and no signing boilerplate:
If you build with rattler-build directly, the same flag is available on both publish (build and upload in one go) and upload prefix (for packages you have already built):
In both cases the tool takes each .conda file individually, mints a fresh OIDC token from the CI runner, creates one CEP-27 attestation per package, and uploads each package together with its bundle.
That per-package detail matters. Per CEP-27, a publish attestation describes exactly one .conda artifact, and its subject carries a single name and digest. A multi-output recipe or a matrix build therefore needs one bundle per package. Handing a glob like **/*.conda to a tool that emits a single bundle covering every match does not produce a compliant attestation, and the upload will fail to verify. --generate-attestation handles this for you, which is why it is the recommended path for multi-output and matrix builds.
Two things to know: --generate-attestation works when publishing to prefix.dev channels, and it requires Trusted Publishing (OIDC), so it cannot be combined with an API key. On upload prefix you can add --store-github-attestation to also push the bundle to GitHub's attestation API, so it shows up in your repository's attestations tab.
The manual way, with actions/attest
This is how the flow looked before --generate-attestation existed, and it is still what you want if you need to customize the predicate, sign with an external trust root, or otherwise can't use the built-in signing.
Because each attestation must cover exactly one package, the attest and upload steps run once per .conda artifact. Note that subject-path points at a single file, because a glob that resolves to more than one file produces a non-compliant bundle.
If your build produces more than one .conda file, actions/attest must be invoked once per package. The common pattern is a matrix strategy that fans out one job per package, calls actions/attest once per job, and uploads the resulting (package, bundle) pair.
You will then be able to find the attestations on:
Github: https://github.com/prefix-dev/sigstore-example/attestations/10209596
The public goods instance of sigstore: https://search.sigstore.dev/?logIndex=456061810
Prefix.dev: https://prefix.dev/channels/sigstore-example/packages/signed-package
We have a comprehensive example that also shows how to verify the signatures using the gh CLI. It's possible to validate signatures using cosign, sigstore-python or sigstore-ruby as well, of course. The full source code for the example and an extensive README can be found here: https://github.com/prefix-dev/sigstore-example.
As we're rolling out the Sigstore support on prefix.dev as a public beta, we hope to see many of our users try it out. During the beta phase, it will be free for everyone. It will always remain free for public open source channels. For users with private channels or public channels distributing closed source software, we will roll out pricing tiers later this year.
If you are interested in using Sigstore, but your organizations needs are not met with our current GitHub Actions integration, we would love to chat. It is absolutely possible to support Gitlab or other CI providers that implement OIDC for trusted publishing and Sigstore attestations and we are happy to prioritize this based on demand.
We are happy to take the next step in modernizing the Conda ecosystem and to provide the fastest and most modern conda channel experience in the world (with sharded repodata, trusted publishing, Sigstore, and more ground breaking features coming soon)!
The Sigstore CEP-27 was made possible thanks to a Small Development Grant by NumFOCUS. And again, a big thank you to our collaborators from Trail of Bits for helping us to push this over the finish line and their tremendous insights into Software Supply Chain Security with Sigstore.
There are a number of next steps for software supply chain security for the Conda ecosystem that we are envisioning:
Re-evaluate TUF (The Update Framework) to secure repodata.json
Think about "counter-signing" for an even stronger link between target channel and the artifact (this would add a transparency log entry when the server receives the package). NPM does this for their sigstore implementation.
Add a protocol to make it easier to retrieve the attestations (e.g. make the attestations available as a bundle under package-name.conda.sigstore right next to the package file)
We are lucky to have been awarded an OpenSSF grant to continue this work! If you are interested in discussing these items, join the Conda Community calls where we present our ideas regularly or join our Discord server to chat!
# Build and publish in one go
rattler-build publish ./recipe.yaml --to https://prefix.dev/my-channel --generate-attestation
# Or upload one or more pre-built packages
rattler-build upload prefix -c my-channel ./output/**/*.conda --generate-attestationname: Build and publish with attestation
on: [push]
jobs:
build:
runs-on: ubuntu-latest
permissions:
# Needed for OIDC: both Trusted Publishing and the Sigstore certificate.
id-token: write
contents: read
steps:
- uses: actions/checkout@v4
- uses: prefix-dev/setup-pixi@v0.8.0
# Build and publish in one step - no stored secrets, no separate signing step.
- run: pixi publish --target-channel https://prefix.dev/my-channel --generate-attestationname: Package and sign
on: [push]
jobs:
build:
runs-on: ubuntu-latest
# These permissions are needed to create a sigstore certificate.
permissions:
id-token: write
contents: read
attestations: write
steps:
- uses: actions/checkout@v4
- name: Build conda package
uses: prefix-dev/rattler-build-action@v0.2.34
# GitHub's official attest action with the Conda predicate.
# subject-path MUST point at a single .conda file.
- uses: actions/attest@v1
id: attest
with:
subject-path: ./output/linux-64/my-package-0.1.0-h123_0.conda
predicate-type: "https://schemas.conda.org/attestations-publish-1.schema.json"
predicate: '{"targetChannel": "https://prefix.dev/my-channel"}'
# Note: no API keys needed because we have configured a trusted publisher!
- name: Upload the package
run: |
rattler-build upload prefix -c my-channel \
./output/linux-64/my-package-0.1.0-h123_0.conda \
--attestation ${{ steps.attest.outputs.bundle-path }}