[Technical Initiative Funding Request]: sigstore specifications for the conda ecosystem

[wolfv]

Technical Initiative

Securing Repositories WG

Lifecycle Phase

graduated

Funding amount

25000

Problem Statement

We would like to iron out technical specifications for implementing sigstore for the Conda package management ecosystem

Who does this affect?

Users of Conda packages. Conda packages are binary packages for Windows, macOS and Linux and widely used in scientific computing and beyond.

Have there been previous attempts to resolve the problem?

We are the first ones to tackle sigstore in the Conda ecosystem. A previous attempt was a homegrown TUF solution that never got open source adoption (only in Anaconda enterprise repositories) called "conda-content-trust.

Why should it be tackled now and by this TI?

Sigstore has definitely reached a level of maturity that makes it highly appealing to adopt it for the Conda ecosystem.

Give an idea of what is required to make the funding initiative happen

We would like to write at least two Conda Enhancement Proposals:

• the first proposal about a "predicate" for the Conda ecosystem which should be standardized for attestations in our ecosystem. A preliminary CEP is already being worked on here: https://github.com/conda/ceps/pull/112
• a second CEP to iterate upon the ideas of the first one and going into more details about trust in the conda ecosystem. We would like to think about additional supply chain attack vectors and how we can facilitate more security:
  • Should we use TUF for the repodata.json files that are used as index for all packages in the conda channel?
  • Should channels / index servers countersign packages to verify authenticity?
  • Are the other security mechanisms that we haven't considered yet, or best practices that we can learn from adjacent ecosystems?

What is going to be needed to deliver this funding initiative?

We would like to spend some of the funding on expert counsel (e.g. Trail Of Bits) in order to guide us on the right decisions.

Are there tools or tech that still need to be produced to facilitate the funding initiative?

No response

Give a summary of the requirements that contextualize the costs of the funding initiative

Most of the funding amount will be spent on developer time to research, write and prepare the material for eventual community ratifaction and adoption. Given that sigstore and supply chain security is not a trivial topic, we expect that it takes considerable focus time to come up with an appropriate solution.

Some effort is already being self-funded by prefix.dev and we are already making progress with the first (predicate) CEP, which is why we are estimating a much lower amount for the completion of this work.

Who is responsible for doing the work of this funding initiative?

Wolf Vollprecht, Bas Zalmstra at prefix.dev

Who is accountable for doing the work of this funding initiative?

The conda steering council

If the responsible or accountable parties are no longer available, what is the backup contact or plan?

The conda steering council consists of ~15 people that should all be available to help with this

What license is this funding initiative being used under?

The conda ecosystem uses BSD-3 by default

Code of Conduct

• [x] I agree to follow the OpenSSF's Code of Conduct

List the major milestones by date and identify the overall timeline within which the technical initiative plans to accomplish their goals. Any payments for services, sponsorships, etc., will require LF Legal and Financial review.

• Milestone 1, estimated completion time 2 months after funding: Sigstore Predicate CEP voted and approved
• Milestone 2, estimated completion time 6 months after funding: Supply Chain Security for Conda CEP drafted and discussed, voted and approved
• Milestone 3, estimated completion time 9 months after funding: Community education material prepared and disseminated

If this is a request for funding to issue a contract, then OpenSSF will issue that contract. Please provide a Statement of Work (SOW) that we may review. Any contracting action will take 4-6 weeks to issue.

SOW OpenSSF __ prefix.dev.pdf

[steiza]

/vote

[git-vote[bot]]

Vote created

@steiza has called for a vote on [Technical Initiative Funding Request]: sigstore specifications for the conda ecosystem (#472).

The members of the following teams have binding votes:

Team
@ossf/tac

Non-binding votes are also appreciated as a sign of support!

How to vote

You can cast your vote by reacting to this comment. The following reactions are supported:

In favor	Against	Abstain
👍	👎	👀

Please note that voting for multiple options is not allowed and those votes won't be counted.

The vote will be open for 14days. It will pass if at least 55% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.

[steiza]

I'm in favor of this proposal, and it aligns with the recommendations of the Securing Repos Working Group. We have seen first-hand the security benefit of build provenance in npm, PyPI, Maven Central, Homebrew, and RubyGems.

Maybe one clarifying question - the output of this proposal is two Conda Enhancement Proposals, not a working implementation of build provenance for Conda, correct? Once that work is done, there will be follow-on work to actually implement the proposals? As noted, if approved by the TAC we'll work with staff to identify the exact amount and vendor selection.

[gkunz]

I am in favor of fostering wider adoption of package management security best practices. Additionally, I have the same question as Zach above and appreciate further insights into this. Thanks!

[git-vote[bot]]

Vote status

So far 22.22% of the users with binding vote are in favor and 0.00% are against (passing threshold: 55%).

Summary

In favor	Against	Abstain	Not voted
2	0	0	7

Binding votes (2)

User	Vote	Timestamp
steiza	In favor	2025-04-24 14:56:55.0 +00:00:00
mlieberman85	In favor	2025-04-24 22:47:11.0 +00:00:00
@justaugustus	Pending
@scovetta	Pending
@bobcallaway	Pending
@lehors	Pending
@gkunz	Pending
@marcelamelara	Pending
@camaleon2016	Pending

[wolfv]

Thank you for the comments and the warm reception of the idea :)

Yes, it should be two CEPs that will paint a picture of how Conda can meaningfully adopt Sigstore attestations.

I think we should have an example implementation of the validation logic in Python as part of the outcome of this project which would re-use sigstore-python (or cosign) to demonstrate the flow of the validation.

The implementation on anaconda.org, prefix.dev, Artifactory, Cloudsmith and others, will have to be done by the specific vendors of Conda channels. We should take care that the specs also support vendor neutral S3 and OCI implementations, which can be used as storage backend. For example, the conda-forge project is currently working on a vendor agnostic storage on OCI registries (similar to how Homebrew stores its packages).

The conda-forge project might also have an intermediate server to perform the necessary validation before the package hits the registry which can use the proto-implementation that comes out of this work.

The main work definitely lies in the specification for the Conda ecosystem how to best make use of sigstore.

[camaleon2016]

What happens if during the research process there's a finding that sigstore may not be the best option? I'm not saying it isn't just asking since the front part of the funding is towards verifying sigstore as the right option. Could there be a potential ask for more funding later is the time goes past the 30days in the SOW?

[wolfv]

@camaleon2016 the conda ecosystem already has a history of a homegrown solution (conda-content-trust) that does not seem to be successful because it was never rolled out to open source repositories and it has a lot less traction than sigstore.

There have been concerns about "vendor-lock-in" with regards to sigstore and e.g. PyPI designed their schema in a way that other mechanisms could be used in place if they decide to go for another implementation in the future - so I think if the Conda community wants vendor-neutrality we could design the signature retrieval in a way to facilitate that.

If the outcome is that sigstore does not fit the bill at all, that would be surprising at this point (the discussions have been ongoing since a while in the conda community and many similar ecosystems – PyPI, Homebrew, Rubygems, ... – have adopted sigstore) then I think that would also be a successful outcome and lead us to find something better. Some risk is always associated to research and development.

[steiza]

As we mentioned at the TAC meeting, I will be accountable for the work described in the proposal, as a co-chair of the Securing Software Repositories working group. This proposal aligns strongly with the published recommendations of the working group: https://repos.openssf.org/build-provenance-for-all-package-registries

[lehors]

As we mentioned at the TAC meeting, I will be accountable for the work described in the proposal, as a co-chair of the Securing Software Repositories working group. This proposal aligns strongly with the published recommendations of the working group: https://repos.openssf.org/build-provenance-for-all-package-registries

Thank you for volunteering to be on point, Zach. Could we please get the proposal updated to reflect this? Thanks.

[marcelamelara]

I think this is a worthwhile effort that aligns with the Securing Software Repos WG's mission, and the project timeline is reasonable. Since this is a contractor request, the final funding decision and amount will be made by the OpenSSF GB.

[git-vote[bot]]

Vote closed

The vote passed! 🎉

55.56% of the users with binding vote were in favor and 0.00% were against (passing threshold: 55%).

Summary

In favor	Against	Abstain	Not voted
5	0	1	3

Binding votes (6)

User	Vote	Timestamp
@bobcallaway	In favor	2025-04-29 14:50:32.0 +00:00:00
@mlieberman85	In favor	2025-04-24 22:47:11.0 +00:00:00
@marcelamelara	In favor	2025-04-29 22:57:39.0 +00:00:00
@steiza	In favor	2025-04-24 14:56:55.0 +00:00:00
@lehors	Abstain	2025-04-28 13:32:45.0 +00:00:00
@scovetta	In favor	2025-04-28 18:05:43.0 +00:00:00

[afmarcum]

Approved by GM

[wolfv]

Exciting! :) Thanks!

[kj-powell]

Contract is signed