Skip to content

Conversation

@woodruffw
Copy link

WIP; just pushing something up for visibility 🙂

Signed-off-by: William Woodruff [email protected]

Comment on lines +139 to +141
- `targetChannel` **MUST** be a string, indicating where the package
is being uploaded to. This field **MUST** be a valid URL with no
trailing slashes.
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Flagging: the original language said "canonical URL" for the targetChannel, but I couldn't find a clear resource on what canonicalization of channel URLs looks like in the conda ecosystem. Does conda have a definition for a "canonical" URL, or by "canonical" did you mean something like "official"?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this is becoming a bit of a problem for the conda ecosystem these days. Currently, when you say -c conda-forge, the URL is resolved to https://conda.anaconda.org/conda-forge which is the "default" place for teh open source channels. But I think we want to be more precise and you should indicate the URL that matches exactly with the channel that you would also download the package from later, whcih can reside on different hosts (for example, for prefix.dev it would look like https://prefix.dev/my-channel).

A channel / organization would have to decide for themselves where the primary channel lives (and which URLs are merely mirrors). For example, for conda-forge right now this would be https://conda.anaconda.org/conda-forge. At some point the organization might decide to switch to https://prefix.dev/conda-forge - at which point we'd have to configure clients to trust either those two, or make a decision based on a timestamp which one is the primary source during what periods.

I also have a proposal open for a community governed channel registry that would live e.g. as a JSON file on Github: conda#91

@wolfv wolfv marked this pull request as ready for review April 23, 2025 14:11
@wolfv wolfv merged commit 7882ad1 into wolfv:sigstore-cep Apr 23, 2025
@woodruffw woodruffw deleted the ww/sigstore-cep branch April 29, 2025 16:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants