doc: update quick start for verifying using ts/tp

[yizha1]

Update quick start document for verifying using trust store and trust policy

Signed-off-by: Yi Zha [email protected]

[netlify]

❌ Deploy Preview for notarydev failed.

Name	Link
🔨 Latest commit	4e8df03
🔍 Latest deploy log	https://app.netlify.com/sites/notarydev/deploys/6364f2849c61e5000cf36fc0

[zr-msft]

blocked on errors to complete smoke test of the doc

[dtzar]

Didn't test the workflow but looks good with just a couple suggestions.

[jeremyrickard]

This should be explicit. Is it the registry? Is it the repo minus an image? Does someone have to specify this for every image they want to validate?

[jeremyrickard]

For what it's worth, with the current version I had to include the image specifically:

cat <<EOF > $HOME/.config/notation/trustpolicy.json
{
    "version": "1.0",
    "trustPolicies": [
        {
            "name": "upstream",
            "registryScopes": [ "upstream.azurecr.io/oss/fluxcd/flux" ],
            "signatureVerification": {
                "level" : "strict" 
            },
            "trustStores": [ "ca:trust" ],
            "trustedIdentities": [
                "*"
            ]
        }
    ]
}
EOF

If I omitted "flux" I ended up getting errors:

ERROR: artifact "upstream.azurecr.io/oss/fluxcd/flux@sha256:0f9ad5df470963f959bb3e0b7abe60e9b4011a636e566a06e883ed7b3812dbc4" has no applicable trust policy

Signature verification failed for all the 0 signatures associated with digest: sha256:0f9ad5df470963f959bb3e0b7abe60e9b4011a636e566a06e883ed7b3812dbc4

Error: artifact "upstream.azurecr.io/oss/fluxcd/flux@sha256:0f9ad5df470963f959bb3e0b7abe60e9b4011a636e566a06e883ed7b3812dbc4" has no applicable trust policy

You should allow wild cards here or something. From an end user perspective if I have to build a trust policy that includes every image I want to validate, that becomes an issue when I build any additional images and is a cumbersome experience.

[dtzar]

upstream.azurecr.io/* should work and ["$REPOSITORY/*"] should be in the example

[jeremyrickard]

I’ll give that a try!

[yizha1]

According to the spec, the repository URI MUST NOT contain the asterisk character *. You can just use ["*"] as a global scope for a quick start.

[yizha1]

Thanks for the additional clarification. So in summary:

Option 1: Trust everything Option 2: enumerate every image you will verify?

@jeremyrickard , you can specify a repo, then all the artifacts under the repo will be verified against the policy. For example, you have images under repo localhost:5000/net-monitor

• localhost:5000/net-monitor:v1
• localhost:5000/net-monitor:v2
• localhost:5000/net-monitor:v3

you just need to specify localhost:5000/net-monitor for registryScopes parameter.

[yizha1]

Check here for more scenarios: https://github.com/notaryproject/notaryproject/blob/main/trust-store-trust-policy-specification.md#trust-policy-schema

[jeremyrickard]

I was talking more about:

localhost:5000/my-service/microservice-1:v1
localhost:5000/my-service/microservice-2:v1
localhost:5000/my-service/microservice-3:v1
localhost:5000/my-service/microservice-4:v1

I would need to explicitly add those. It's fine that things are called out in that spec, but there should be a little more detail (imo) on the quick start about this. People are going to read this and if you expect them to click through to other pages for crucial information for anything more I think you'll lose people.

[yizha1]

Thanks @jeremyrickard. Does the following configuration work for you? Or you think it is still too much to configure many repositories.

"registryScopes": [
              "localhost:5000/my-service/microservice-1",
              "localhost:5000/my-service/microservice-2",
              "localhost:5000/my-service/microservice-3",
              "localhost:5000/my-service/microservice-4"
            ],

[dtzar]

@yizha1 - yes this is far too much work! We need to add a backlog item to support all images coming from a registry.

[FeynmanZhou]

If we use $HOME/.config/notation/localkeys here, I suggest adding a prerequisite at the beginning of this doc to claiming that this Quick Start is using a Linux environment as an example. Since this path is different per OS.

[FeynmanZhou]

We can also add an inner link to another document that introduces the path when it is merged into the website.

[FeynmanZhou]

Please see my comments above. Thanks!

[chalin]

The build for this PR was failing, but it was still merged so now the main production build is broken, see: https://app.netlify.com/sites/notarydev/deploys/636b1cd5300a5300084d80b4. That means, as you probably know, that the site won't deploy anymore until the build is fixed. /cc @nate-double-u

It seems that this PR has two broken links, that's why the build was failing.

[chalin]

Generally, it's best to keep the production built free of errors, but our project's build policy might be different, in which case: apologies, and you can ignore my comments above.

[zr-msft]

I believe #92 fixed the build errors related to this PR

[chalin]

@zr-msft: yes, great!