Proposal for generic reverse lookup #14
Conversation
aviral26
force-pushed
the
prototype-1
branch
from
8c3a625 to
9948393
Compare
Signed-off-by: Aviral Takkar <aviral26@users.noreply.github.com>
aviral26
force-pushed
the
prototype-1
branch
from
9948393 to
bf490b8
Compare
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
Signed-off-by: Aviral Takkar <aviral26@users.noreply.github.com>
Update to reflect current prototype
|
|
||
| ## Persisting Referrer Metadata (Signatures) | ||
|
|
||
| The proposal implements a referrer metadata store for manifests that is essentially a reverse-lookup, by `mediaType`, to referrer config objects. For example, when an OCI index is pushed, if it references a config object of media type `application/vnd.cncf.notary.config.v2+jwt`, a link to the config object is recorded in the referrer metadata store of each referenced manifest. |
There was a problem hiding this comment.
How do you generate the response in section referrer-metadata API with such data structure? IMO the linkage is between the referrer and the manifest, rather than between the config object of the referrer and the manifest.
There was a problem hiding this comment.
/cc @SteveLasker to comment on the requirement for including complete descriptors in the response
@reasonerjt , you're right. The linkage is between the referrer and the manifest. However, with this approach, we get some optimization for referrer metadata lookups since clients would ask for referrer config objects when requesting signatures. What scenarios would require a client to query the list of referrers for a manifest?
|
|
||
| ```shell | ||
| # Retrieve first signature and store it locally | ||
| metadataDigest=`curl -s "http://$registry/v2/$repo/manifests/$manifestDigest/referrer-metadata?media-type=$metadataMediaType" | jq -r '.referrerMetadata[0]'` && \ |
There was a problem hiding this comment.
It seems the response is not consistent with the one in the section referrer-metadata API
| ### referrer-metadata API | ||
|
|
||
| ```HTTP | ||
| `GET http://localhost:5000/v2/net-monitor/manifests/11wma2d22ae5ef400769fa51c84717264cd1520ac8d93dc071374c1be49a11wm/referrer-metadata` |
There was a problem hiding this comment.
From API's perspective, IMHO, it would be a better design if we first introduce the referrer API, which returns all referrer, including the optionally selected metadata, such as the digest of config blob.
The caller may filter the result by adding config-mediaType to the query string.
More like the option 1 you described in #13
|
@reasonerjt, we've moved onto prototype-2, which implements the current oci.artifact.manifest or #29 I'm going to merge this one, just as we're no longer making changes to prototype-1. Please review https://github.com/notaryproject/nv2/tree/prototype-2 and open any issues you'd like to see discussed. |
Add a proposal for tracking referrer metadata for each manifest and using this ability to store and retrieve signatures. The idea is illustrated using a prototype implementation.