@beckermr how would you feel about making it an optional field? I think if the field exists, it should be validated.

I thought the predicate had to be non-empty in order to sign at all?

Nope, it can be totally empty (that is what PyPI uses). But PyPI only has a single canonical source (channel). We have more channels, therefore we want to add a single targetChannel.

Ah ok. Yes. I'm happy to have it be optional, but if it is present it must be validated. I'll change my review.

Not to be overly pedantic, but SigStore itself does not have the concept of "attestations"; it's instead a framework for signing arbitrary artifacts (what it calls "verification materials") using short-lived keys, tying those keys to an identity, and logging the signing event to a transparency log.

One of the verification materials that can be signed using SigStore are attestation, but those attestations need to be defined under some other framework.

This single sentence abstract seems to be too broadly scoped. In particular, "attestations" can mean a lot of things, and a single package artifact could have zero or more attestations for it, depending on the various security/threat models being attested to.

We should be absolutely clear about what the predicate being described in CEP is attesting to. Is it to the integrity of the package during transport between the build system and the hosting server, akin to PyPI Trusted Publishing? Provenenace information about the build process itself, a la SLSA? Both? Or something else entirely?

Is the subject field constrained to one and only one package? Or are there circumstances in which multiple packages can be covered by a single attestation?

Still an open question (per the current spec, subject is one-package only), but worth calling out that the comment is un-answered.

Thanks, I forgot to answer directly here: this CEP as-drafted proposed only a single package subject at a time, since allowing multiple subjects introduces (IMO) a degree of malleability that makes downstream usage harder.

To be precise: if an attestation is allowed to contain multiple subjects, a malicious party could do something like:

subjects:
  authentic-0.0.1-etc.conda
  inauthentic-0.0.1-etc.conda

...where the authentic package identity is one they're authorized (via the server) to publish for, while inauthentic is some other package they aren't authorized for. This is turn would make it easy for the server to accidentally accept "mixed" attestations and re-broadcast them as if they're "fully" verified.

This is mentioned under the Verifying section as well:

Servers SHOULD perform the same verification process as clients,
with the qualification that the server's trust in the signing identity
is established latently via the server's publishing and upload mechanism.
For example, if the server supports [Trusted Publishing], then the package's
attestation should be verified against the set of Trusted Publisher identities
for that package.

What does the predicate material attest to? Target channel makes it seem like what we want to attest to is some like PyPI Trusted Publishing, but that is not at all clear from the content of this proposed CEP.

If what we want to attest to are claims about the security of build process (a la SLSA), this predicate specification is definitely not sufficient.

Some other notes:

...[channel where the] package is being uploaded to...

We might want to clarify or refine that clause. I might be wrong, but a strict reading of that could mean that channel value for conda-forge should be "cf-staging", not "conda-forge". (Since packages are initially uploaded to "cf-staging" and then copied over to "conda-forge".)

channel MUST be in canonical form

We need some reference defining what "canonical form" means. I'm not sure there's consensus of a "canonical" channel in the conda-verse, since packages are perhaps surprisingly mobile across channels.

I wouldn't want to generalize from what conda-forge does. We could very well special case how we validate packages for conda-forge based on the workarounds that are currently applied, but I don't think it's a nice situation that conda-forge is in from which we should spec out how we want to deal with sigstore.

conda-forge could decide to upload to a S3 bucket first, and then upload to the conda-forge channel, with another Github Action that also makes OIDC trusted publishing work, as an example.

As such, I don't think this needs any clarification.

And yes, for the canonical form, I propose to use the FULL URL for the channel without trailing slash, e.g. https://anaconda.org/conda-forge. This has nothing to do with packages being mobile, which is another concern that we could solve in a number of ways (not relevant here).

It's not clear to me what which server is meant here, nor what chain of trust is being established. (Missing threat model in the CEP.)

The current CEP still seems to be missing a sense of "what threat will/may this protect against" - It would be great to flesh that out a bit, rather than simply the "what are we specifying in the attestation"

I hope the rewrite clarifies this! LMK if not.

Still an open question (per the current spec, subject is one-package only), but worth calling out that the comment is un-answered.

The motivation still seems mostly catered toward "attestations in general" and makes very little mention that this is "attesting about the publication metadata". I wonder if this could be slightly reworded to emphasize the actual goals of publish/v1

Any suggestions how to reword it?

The current CEP still seems to be missing a sense of "what threat will/may this protect against" - It would be great to flesh that out a bit, rather than simply the "what are we specifying in the attestation"

Sorry if this is an obvious question, but what are the contents of https://schemas.conda.org/attestations/publish/v1? Or is it just a string identifying this attestation format? i.e. is it empty?

The type field should contain this exact string. The other fields of the dictionary should contain the fields as specified in the schema.

Ah OK, you mean what we would see when clicking that URL. Yes, probably we should provide a real JSON schema that we would have behind that URL already..

Yeah, having that URL provide a JSON schema would be reasonable. Another option would be to have it serve an HTML page with a render of the schema or just a description thereof, which is what PyPI does:

https://docs.pypi.org/attestations/publish/v1/

Let's go for the JSON schema as Jannis suggested, and let's open the relevant PR in https://github.com/conda/schemas to provide the file.

draft PR for the schema opened: conda/schemas#76

nit: I feel like composes is a bit more correct?:

"Sigstore composes with X to provide Y" vs. "Sigstore works with X to provide Y"

alternatively, this could also be "Sigstore uses X to provide Y"

@jezdez wdyt?

fixed, changed to Sigstore uses attestation frameworks like in-toto...

Seems like this section is indented oddly

Ah, I think pre-commit also found something

fixed

Alright, so the targeted attack is publicly discoverable, wouldn't that just reduce the time the attacker has to run the attack, exfiltrate data etc? Can you say something about how this added transparency influences the ability to defend against targeted attacks?

Can you say something about how this added transparency influences the ability to defend against targeted attacks?

Yeah, can do -- the idea is that in the context of targeted attacks, the victimized party (i.e. the one the attacker is impersonating) can monitor for uses of their identity in real time, meaning that they can respond proactively to the compromise instead of waiting for the first report of compromise from a downstream. I'll fill that in.

Fixed, added more about how the transparency log helps detecting and responding to compromises:

Because a valid transparency log inclusion proof is a requirement during
verification, an attacker who compromises a signing identity *cannot*
perform a targeted attack without making the attack itself publicly
discoverable. This means the log can be monitored in real time for
uses of identities, allowing users to proactively detect and respond
to an identity being compromised, rather than having to wait for the
compromise being detected downstream and reported.

I think it might be good to mention mirrors here again?

fixed, added mention of how target channels are verified and how mirrors might be handled:

This predicate adds basic verifiable facts about the package. It will tie the
producer of the package to the target channel, if the attestation's producer
chooses to do so. A verifier can then use this information during the
verification process, checking that the target channel matches the channel the
package was retrieved from, or ignoring a mismatch between channels when the
package is retrieved from a mirror.

fixed

As a stylistic note, we should add something like this, since it looks like we're using "MUST" in the RFC2119-way:

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119][RFC2119] when, and only when, they appear in all capitals, as shown here.

More specifically, violations of a MUST or MUST NOT rule MUST result in an error. Violations of the rules specified by any of the other all-capital terms MAY result in a warning, at discretion of the implementation.

fixed

Yes, please, let's fix this.

Let's go for the JSON schema as Jannis suggested, and let's open the relevant PR in https://github.com/conda/schemas to provide the file.