Using Verifier without a repository

[etrexel]

Hello Notation Maintainers,

We have been using notation-go v0.8.0-alpha.1 for notaryv2 signature validation in the ratify project. As part of ratify-project/ratify#274 we have been looking at updating to notation-go v0.10.0-alpha.3 to take advantage of some of the added trust store features, but have run into some challenges with integrating the new Verifier type.

In ratify we have a core executor that performs artifact verification for a provided subject by collecting artifact references from stores and verifying them with the appropriate verifiers. This means that when we call a verifier we have already retrieved the associated artifact from the registry. In our existing notaryv2 verifier implementation we use the Verify function and pass the signature, but in the new Verify function the verifier expects to retrieve all of the references itself and verify all of them in one call. Would it be possible to expose some of the functionality in the new Verifier type to operate on pre-fetched signatures?

I took a look at the Verify implementation it looks like it would fit our use case to call processSignature directly. Ideally we would like to use the Verifier without having to provide a repository since our execution model separates repositories and verifiers. Do you have any suggestions or concerns with this approach?

Thanks!

@shizhMSFT @binbin-li @dtzar

[shizhMSFT]

@FeynmanZhou @yizha1 This is related to notaryproject/roadmap#15.

/cc @patrickzheng200 @gokarnm @priteshbandi

[FeynmanZhou]

I think we need to clarify the target and expected date for resolving this issue. May I know the ETA date of Ratify v1.0.0 Beta? Will this issue block the development of Ratify v1.0.0 Beta? @dtzar @etrexel

• As Notation had a plan ([User Story] - notation sign/verify Offline/Local artifacts roadmap#15) to support local signing, which will solve this issue and deliver an end-to-end user experience with CLI and Go SDK after RC.1 (Maybe we need to prioritize this plan to RC.2).
• If you are very close to the ETA date of Ratify v1.0.0 Beta, I would suggest Notation maintainers refactor the Verify function to resolve this issue specifically in Go SDK first (within Notation RC.1).

[dtzar]

I suggest we prioritize the local sign/verify user story as a high priority after RC.1 and release a point-release just for notation-go so ratify and other can utilize it.

[priteshbandi]

I think the ask here is to expose a public function (like processSignature) that takes signature, TS/TP as input, and performs signature verification without making any calls to the registry.
This can be done via small refactoring.

Rakesh to update issue with example how it can be done with existing functions

[rgnote]

@etrexel

The new Verifier accepts an interface to Repository

You can achieve your goals by implementing a local Repository that returns your pre-fetched signatures. You will have to implement GetSignatureManifests, GetBlob, Resolve methods. You can make PutSignatureManifest as no-op since signature verification doesn't write to the repository.

Take a look at this mock repository which I think is closer to what you are trying to do.

[binbin-li]

@rgnote Thanks for your suggestion. But it might not be a good short-term workaround to Ratify. It seems a lot of boilerplate for functionality from notation-go. Also we need a ton of refactoring in Ratify to support it. Since Ratify is not in a hurry to use the new verifier, I feel we can wait for a fully support of offline verification from notation-go. @etrexel please correct me if I'm wrong.

[rgnote]

@binbin-li

This suggestion is not a short-term workaround. We implemented the new Verifier with Repository interface just to support usecases like Ratify's. Implementing a local Repository with pre-fetched signature doesn't require a ton of boilerplate. All Ratify needs to do is have a bare minimum Repository implementation that passes the pre-fetched signature to Verifier, which can be done under 30-40 lines of code. This is a much cleaner path in-terms of simplicity and understandably than Verifier exposing another public function.

I want to call out that supporting offline signature verification is more complex than just supporting verification on pre-fetch signatures. Offline signature verification requires us to think about revocation, verification using plugin, etc.

[patrickzheng200]

After the refactoring work of notation-go, this issue is resolved. Closing it.