notaryproject / notation-go

A collection of libraries for supporting sign and verify OCI artifacts. Based on Notary Project specifications.
Apache License 2.0
39 stars 42 forks source link

Payload Mediatype and certificate thumbprint annotation constants are not exported for API consumers #398

Open c-grund opened 6 months ago

c-grund commented 6 months ago

What is not working as expected?

The constants defined in internal/envelope/envelope.go

MediaTypePayloadV1            = "application/vnd.cncf.notary.payload.v1+json"
AnnotationX509ChainThumbprint = "io.cncf.notary.x509chain.thumbprint#S256"

are not exported, and therefore not available for consumers of the sign and verify API. Since these are required values per the specification, programs that wish to work with notation signatures must duplicate these constants.

What did you expect to happen?

These constants should be available through a public notation-go or notation-core-go export

How can we reproduce it?

Attempt to access these required constant values from external code.

Describe your environment

Linux/Go 1.22

What is the version of your notation-go Library?

notation-go v1.1.0 notation-core-go v1.0.2

Two-Hearts commented 6 months ago

That's a good idea. @c-grund may I ask what you are trying to do that requires the export of these two variables?

c-grund commented 6 months ago

I'm working on set of tools that can sign and verify signed custom oci objects (among other things). We're using notation as a library for one of the signature formats. Despite performing sign/verify through the API, we want to maintain compatibility with the Notation CLI for performing those functions, and thus wish to stick close to the spec. The constants referred to here are marked as MUST items, so we'd rather not redefine them in our code.

shizhMSFT commented 1 month ago

This issue requires a revisit since general developers should not re-invent the wheel for signing and verification.

@c-grund I can understand that you need AnnotationX509ChainThumbprint for OCI signature filtering. May I ask why you require MediaTypePayloadV1 to be exposed as it should be completely hidden from the end users?

FeynmanZhou commented 1 week ago

@c-grund May I know if this issue is still critical for your scenario?

c-grund commented 1 week ago

Sorry for the delay in response.

I've moved on to a new project, but when I last worked with this scenario, I believe we got away from needing to use MediaTypePayloadV1. I think at one point we were directly constructing the payload, and in order to maintain compatibility with the spec we wanted to use the library defined constant for the media type data. Since then, we dropped the requirement that led us to building the payload ourselves, and therefore no longer needed to access the library constant.