cosign verify-blob seemingly does not work with chains attestations.

Open vaikas opened this issue 2 years ago • 9 comments

Expected Behavior

Actual Behavior

It does not seem to work for me. If I decode the payload with the base64 the tlog entry can not be found. Cosign sez:

Error: verifying blob [./payload]: could not find a tlog entry for provided blob

If I do not base64 decode the payload (remove the | base64 -d), so change the fetch line to:

tkn tr describe --last -o jsonpath="{.metadata.annotations.chains\.tekton\.dev/payload-taskrun-$TASKRUN_UID}" > payload

Cosign at least finds the entry:

Error: verifying blob [./payload-unencoded]: unexpected tlog entry type

But, looking at the cosign code: https://github.com/sigstore/cosign/blob/main/cmd/cosign/cli/verify/verify_blob.go#L338-L351

It does not support the intoto type, which the payload is.

If I add intoto support into cosign verify_blob, it now fails to verify the signature. You can see how I did that here: https://github.com/sigstore/cosign/compare/main...vaikas:intoto-verify-blob?expand=1

Error: verifying blob [./payload-unencoded]: failed to verify signature

So, I guess I believe there are two issues here:

Mismatch between whether to decode the payload created by Chains or not before using it for Cosign.
Chains writes the entry type that's not expected, or somehow it's not recognized by cosign verify_blob
If intoto is supposed to work with verify_blob in cosign, then support to that seems to be added for this to work.

The intoto object that cosign does get back from rekor is like so:

&{IntotoObj:{Content:0x1400060e8e8 PublicKey:LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVLRENDQWhDZ0F3SUJBZ0lSQUxVdDM1ZmVRMHYxc3RBR1lMaUUyblV3RFFZSktvWklodmNOQVFFTEJRQXcKYWpFTU1Bb0dBMVVFQmhNRFZWTkJNUXN3Q1FZRFZRUUlFd0pYUVRFUk1BOEdBMVVFQnhNSVMybHlhMnhoYm1ReApGVEFUQmdOVkJBa1RERGMyTnlBMmRHZ2dVM1FnVXpFT01Bd0dBMVVFRVJNRk9UZ3dNek14RXpBUkJnTlZCQW9UCkNtTm9ZV2x1WjNWaGNtUXdIaGNOTWpJd01qRTNNVFl3TnpVM1doY05Nakl3TWpFM01UWXhOelUzV2pBQU1Ga3cKRXdZSEtvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQUVIdnVpZldYYVhTSjEwaThLeitFTlVwVDg5eWE3MGtmeAoxN3FEb2UwWHpzQWlOUU5DeFFWQWR1Y2NMdU5keE5OdlI3VHZkOWZDVHk4dUxuaEk5VU5TZDZPQi9UQ0IrakFPCkJnTlZIUThCQWY4RUJBTUNBZ1F3RXdZRFZSMGxCQXd3Q2dZSUt3WUJCUVVIQXdNd0hRWURWUjBPQkJZRUZOUDMKTlkwZitLemxHT0hWQ1Z2MDFVQ0FlcE1MTUI4R0ExVWRJd1FZTUJhQUZHSVFtZCtibFYwZVlIUi8ybzcwWUpCagpqUDBsTUdVR0ExVWRFUUVCL3dSYk1GbUdWMmgwZEhCek9pOHZhM1ZpWlhKdVpYUmxjeTVwYnk5dVlXMWxjM0JoClkyVnpMM1JsYTNSdmJpMWphR0ZwYm5NdmMyVnlkbWxqWldGalkyOTFiblJ6TDNSbGEzUnZiaTFqYUdGcGJuTXQKWTI5dWRISnZiR3hsY2pBc0Jnb3JCZ0VFQVlPL01BRUJCQjVvZEhSd2N6b3ZMMnQxWW1WeWJtVjBaWE11WkdWbQpZWFZzZEM1emRtTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnSUJBRWlMS0FwWnNGakdDczdrNG1jY2E4bThrb0VBCnRFamovZm41WGxXUjNNb3lkYzl3WFovS3FIRXFOeHgveG81WWxOTEVRYjN5MnZIWjg2WUVwcEI0emc2SCtPSEQKV0NRUzhlZFJsZC9JQmRQQnZvUEVTeE1CalE2QzNpVkVjTGNSZ2hGN2IvQyszWGJwZk5hZngyY2lHU3RySmZzMwo3YWY1Ujd0S2pDdkFHOS95K0M0bm9lR0tRM0VoTWl0T3JOd2o5aTRxVWNwWk1rK1ByM3p3T3k2WGluNHcwN0wzClB4SXJYMnBSYXQwVnoxaHlDR3FubE9zWkgwazVsWlJPUFI3TVdxeDhGVWMzeVNMdUF5V0RuRnN0OGVVdHN5cXoKWTBiZFc1RTBWNVk2V2VhNXpNMW9id2lqRXZJbmVrNzFQLzJBdFBNSktiTkVVMkU1OERqU1BheldjTXdmQXQ5agpYTnFCdkgyWURBZ3d2WGVHNU5iRlJjVmVselhVUHBPVDdhbHdvRXhaTHpIVnFzdEdCQWVXUWpSYUJVOSszbG1zCmEvNHVqRHBUanpxZloxbmRpNGZyT3k3SHgzS1A5YWxwUWVCSjRxUmdhWXFBV2NXSXQ4R2xEY0YydDg3dlkyNmUKY2dNdWdSRHcySWdxVTE2alhWWnZZRkdVdWo1eTBTYzVLZ0lZNEhUL3lrd0hHa0tualFXL1hET2lCeC8yNU5POQp4dG4veGJjREJjTGhodFN0MzB3a0RIT2k2NW1tVTlqamViL3drdHVnVElLVm1zNHJMOGFsRm5mdDlvdnJJVVNLClhLZUcxMHdLTkYxWUNkRklLc2dMNFRkRENoTDhsK0RLNnY3UGV6TDVIWmtIZnEyOURySHc0NG0xL1M0VXJ6RnMKOHNHRWxxRVd4RmczTVplVgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==} keyObj:0x1400060e9d8 env:{PayloadType: Payload: Signatures:[]}}

And the payload that's stored in Chains (decoded with base64 -d as instructed) is like so:

{"_type":"https://in-toto.io/Statement/v0.1","predicateType":"https://slsa.dev/provenance/v0.2","subject":null,"predicate":{"builder":{"id":"https://tekton.dev/chains/v2"},"buildType":"https://tekton.dev/attestations/chains@v2","invocation":{"configSource":{},"parameters":{"BUILDER_IMAGE":"gcr.io/kaniko-project/executor:latest","CONTEXT":"./","DOCKERFILE":"./Dockerfile","EXTRA_ARGS":"[]","IMAGE":"{string registry.local:5000/knative/pythontest:0.1 []}"}},"buildConfig":{"steps":[{"entryPoint":"/kaniko/executor $(params.EXTRA_ARGS) --dockerfile=$(params.DOCKERFILE) --context=$(workspaces.source.path)/$(params.CONTEXT) --destination=$(params.IMAGE) --oci-layout-path=$(workspaces.source.path)/$(params.CONTEXT)/image-digest","arguments":null,"environment":{"container":"build-and-push","image":"gcr.io/kaniko-project/executor@sha256:0fae223f496525e31226cde473ec77ed15abfa8cbabff5ff5bf1c5268355bbb0"},"annotations":null},{"entryPoint":"/ko-app/imagedigestexporter","arguments":["-images=[{\"name\":\"$(params.IMAGE)\",\"type\":\"image\",\"url\":\"$(params.IMAGE)\",\"digest\":\"\",\"OutputImageDir\":\"$(workspaces.source.path)/$(params.CONTEXT)/image-digest\"}]","-terminationMessagePath=$(params.CONTEXT)/image-digested"],"environment":{"container":"write-digest","image":"gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/imagedigestexporter@sha256:1f067763fb3c57ef42595b30758a3acffeee301e333bafe983a434097e1b9bd2"},"annotations":null},{"entryPoint":"cat $(params.CONTEXT)/image-digested | jq '.[0].value' -rj | tee /tekton/results/IMAGE-DIGEST\n","arguments":null,"environment":{"container":"digest-to-results","image":"sha256:347be09212d543b6b4b1be11bbc1fb7c9574ae2067f355bc3950673578b4f590"},"annotations":null}]},"metadata":{"buildStartedOn":"2022-02-17T16:07:33Z","buildFinishedOn":"2022-02-17T16:07:57Z","completeness":{"parameters":false,"environment":false,"materials":false},"reproducible":false}}}

Steps to Reproduce the Problem

Additional Info

Kubernetes version:

Output of kubectl version:

Client Version: version.Info{Major:"1", Minor:"21+", GitVersion:"v1.21.9-dispatcher", GitCommit:"2a8027f41d28b788b001389f3091c245cd0a9a60", GitTreeState:"clean", BuildDate:"2022-01-21T20:32:40Z", GoVersion:"go1.16.12", Compiler:"gc", Platform:"darwin/arm64"}
Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.1", GitCommit:"5e58841cce77d4bc13713ad2b91fa0d961e69192", GitTreeState:"clean", BuildDate:"2021-05-21T23:06:30Z", GoVersion:"go1.16.4", Compiler:"gc", Platform:"linux/arm64"}

Tekton Pipeline version:

Output of tkn version or kubectl get pods -n tekton-pipelines -l app=tekton-pipelines-controller -o=jsonpath='{.items[0].metadata.labels.version}'

 kubectl get pods -n tekton-pipelines -l app=tekton-pipelines-controller -o=jsonpath='{.items[0].metadata.labels.version}'
v20220216-137521906c%
 kubectl get pods -n tekton-chains -l app=tekton-chains-controller -o=jsonpath='{.items[0].metadata.labels.version}'
v0.8.0%

Feb 22 '22 01:02 vaikas

I'm using the same chains version but cannot get this error. are you using "tekton" or a different setting(e.g. in-toto, as from your payload content)?

kubectl patch configmap chains-config -n tekton-chains -p='{"data":{"artifacts.oci.storage": "", "artifacts.taskrun.format":"tekton", "artifacts.taskrun.storage": "tekton"}}'

If so, it may be related to https://github.com/tektoncd/chains/issues/329

Feb 22 '22 03:02 Yongxuanzhang

Oops, this is where I wanted to add the comment to, not for #329.

Yeah, I'm using in-toto attestations and my chains config is like this.

kubectl -n tekton-chains get cm chains-config -ojsonpath='{.data}' | jq -r . { "artifacts.oci.format": "simplesigning", "artifacts.oci.storage": "oci", "artifacts.taskrun.format": "in-toto", "signers.x509.fulcio.address": "http://fulcio.fulcio-system.svc", "signers.x509.fulcio.enabled": "true", "transparency.enabled": "true", "transparency.url": "http://rekor.rekor-system.svc" }

I'll dig into those issues more, thanks! I'm using cosign from the head since @priyawadhwa in the past had mentioned some bugs there had been fixed and needed a newer version.

Feb 22 '22 17:02 vaikas

You should be able to verify the signature from the tekton task like this:

tkn tr describe --last -o jsonpath="{.metadata.annotations.chains\.tekton\.dev/signature-taskrun-$TASKRUN_UID}" | base64 -d > sig
cosign verify-blob --key k8s://tekton-chains/signing-secrets --signature sig sig
# Should output `Verified OK`

Since the signature is in the DSSE format, you need to be using the signature annotation, not the payload annotation.

If you would like to see this usage in a full context, we wrote a tutorial here: https://github.com/thesecuresoftwarefactory/ssf/blob/main/examples/buildpacks/dual-storage-backend.md.

Feb 22 '22 17:02 rgreinho

Since the signature is in the DSSE format, you need to be using the signature annotation, not the payload annotation.

Good point, thanks @rgreinho !

I was able to reproduce this, and I passed in the unencoded signature as the "payload" to cosign since this is in DSSE format:

COSIGN_EXPERIMENTAL=1 cosign verify-blob --signature ./signature ./signature-decoded

# additional debugging I added to cosign
searching for hash:  sha256:8721d922ba53b8fed8031a5ce64cff0a1ae7241a840dd022e9de8a319d3f91a3

# error
Error: verifying blob [./signature-decoded]: could not find a tlog entry for provided blob
main.go:46: error during command execution: verifying blob [./signature-decoded]: could not find a tlog entry for provided blob

The relevant entry in Rekor, which has the same sha as above:

rekor-cli get --log-index 1484470
LogID: c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d
Attestation: eyJfdHlwZSI6Imh0dHBzOi8vaW4tdG90by5pby9TdGF0ZW1lbnQvdjAuMSIsInByZWRpY2F0ZVR5cGUiOiJodHRwczovL3Nsc2EuZGV2L3Byb3ZlbmFuY2UvdjAuMiIsInN1YmplY3QiOlt7Im5hbWUiOiJnY3IuaW8vZm9vL2JhciIsImRpZ2VzdCI6eyJzaGEyNTYiOiIwNWY5NWIyNmVkMTA2NjhiNzE4M2MxZTJkYTk4NjEwZTkxMzcyZmE5ZjUxMDA0NmQ0Y2U1ODEyYWRkYWQ4NmI1In19XSwicHJlZGljYXRlIjp7ImJ1aWxkZXIiOnsiaWQiOiJodHRwczovL3Rla3Rvbi5kZXYvY2hhaW5zL3YyIn0sImJ1aWxkVHlwZSI6Imh0dHBzOi8vdGVrdG9uLmRldi9hdHRlc3RhdGlvbnMvY2hhaW5zQHYyIiwiaW52b2NhdGlvbiI6eyJjb25maWdTb3VyY2UiOnt9LCJwYXJhbWV0ZXJzIjp7fX0sImJ1aWxkQ29uZmlnIjp7InN0ZXBzIjpbeyJlbnRyeVBvaW50IjoiIiwiYXJndW1lbnRzIjpudWxsLCJlbnZpcm9ubWVudCI6eyJjb250YWluZXIiOiJjcmVhdGUtZGlyLWJ1aWx0aW1hZ2UtczdubXEiLCJpbWFnZSI6Imdjci5pby9kaXN0cm9sZXNzL2Jhc2VAc2hhMjU2OmNmZGM1NTM0MDBkNDFiNDdmZDIzMWIwMjg0MDM0Njk4MTFmY2RiYzBlNjlkNjZlYTgwMzBjNWEwYjVmYmFjMmIifSwiYW5ub3RhdGlvbnMiOm51bGx9LHsiZW50cnlQb2ludCI6IiIsImFyZ3VtZW50cyI6bnVsbCwiZW52aXJvbm1lbnQiOnsiY29udGFpbmVyIjoiZ2l0LXNvdXJjZS1zb3VyY2VyZXBvLXh2cWdoIiwiaW1hZ2UiOiJnY3IuaW8vdGVrdG9uLXJlbGVhc2VzL2dpdGh1Yi5jb20vdGVrdG9uY2QvcGlwZWxpbmUvY21kL2dpdC1pbml0QHNoYTI1NjowMmZmYzhiMDllNTc1ZDFlZThjZmNjNWE4MjI2M2NlYTU2ZjNmNWZlMDRlYTEwODJiYjA2ZDk4YjViODNkNWU0In0sImFubm90YXRpb25zIjpudWxsfSx7ImVudHJ5UG9pbnQiOiJzZXQgLWVcbmNhdCBcdTAwM2NcdTAwM2NFT0YgXHUwMDNlICQoaW5wdXRzLnJlc291cmNlcy5zb3VyY2VyZXBvLnBhdGgpL2luZGV4Lmpzb25cbntcblwic2NoZW1hVmVyc2lvblwiOiAyLFxuXCJtYW5pZmVzdHNcIjogW1xuICAgIHtcbiAgICBcIm1lZGlhVHlwZVwiOiBcImFwcGxpY2F0aW9uL3ZuZC5vY2kuaW1hZ2UuaW5kZXgudjEranNvblwiLFxuICAgIFwic2l6ZVwiOiAzMTQsXG4gICAgXCJkaWdlc3RcIjogXCJzaGEyNTY6MDVmOTViMjZlZDEwNjY4YjcxODNjMWUyZGE5ODYxMGU5MTM3MmZhOWY1MTAwNDZkNGNlNTgxMmFkZGFkODZiNVwiXG4gICAgfVxuXVxufVxuIiwiYXJndW1lbnRzIjpudWxsLCJlbnZpcm9ubWVudCI6eyJjb250YWluZXIiOiJidWlsZC1hbmQtcHVzaCIsImltYWdlIjoiZG9ja2VyLmlvL2xpYnJhcnkvYnVzeWJveEBzaGEyNTY6YWZjYzdmMWFjMWI0OWRiMzE3YTcxOTZjOTAyZTYxYzZjM2M0NjA3ZDYzNTk5ZWUxYTgyZDcwMmQyNDlhMGNjYiJ9LCJhbm5vdGF0aW9ucyI6bnVsbH0seyJlbnRyeVBvaW50IjoiY2F0ICQoaW5wdXRzLnJlc291cmNlcy5zb3VyY2VyZXBvLnBhdGgpL2luZGV4Lmpzb24iLCJhcmd1bWVudHMiOm51bGwsImVudmlyb25tZW50Ijp7ImNvbnRhaW5lciI6ImVjaG8iLCJpbWFnZSI6ImRvY2tlci5pby9saWJyYXJ5L2J1c3lib3hAc2hhMjU2OmFmY2M3ZjFhYzFiNDlkYjMxN2E3MTk2YzkwMmU2MWM2YzNjNDYwN2Q2MzU5OWVlMWE4MmQ3MDJkMjQ5YTBjY2IifSwiYW5ub3RhdGlvbnMiOm51bGx9LHsiZW50cnlQb2ludCI6IiIsImFyZ3VtZW50cyI6bnVsbCwiZW52aXJvbm1lbnQiOnsiY29udGFpbmVyIjoiaW1hZ2UtZGlnZXN0LWV4cG9ydGVyLTUyNWdzIiwiaW1hZ2UiOiJnY3IuaW8vdGVrdG9uLXJlbGVhc2VzL2dpdGh1Yi5jb20vdGVrdG9uY2QvcGlwZWxpbmUvY21kL2ltYWdlZGlnZXN0ZXhwb3J0ZXJAc2hhMjU2OjNjNDkxOGU1ODFiYTViNjdkYjk4MzhlZTM4NDAxMmU0MTllZGE4ZmRjZDcxNjQ0N2Q1ODhjMzNjNzA3M2QwN2IifSwiYW5ub3RhdGlvbnMiOm51bGx9XX0sIm1ldGFkYXRhIjp7ImJ1aWxkU3RhcnRlZE9uIjoiMjAyMi0wMi0yMlQyMDo1MTo0NloiLCJidWlsZEZpbmlzaGVkT24iOiIyMDIyLTAyLTIyVDIwOjUyOjA0WiIsImNvbXBsZXRlbmVzcyI6eyJwYXJhbWV0ZXJzIjpmYWxzZSwiZW52aXJvbm1lbnQiOmZhbHNlLCJtYXRlcmlhbHMiOmZhbHNlfSwicmVwcm9kdWNpYmxlIjpmYWxzZX0sIm1hdGVyaWFscyI6W3sidXJpIjoiZ2l0K2h0dHBzOi8vZ2l0aHViLmNvbS9Hb29nbGVDb250YWluZXJUb29scy9za2FmZm9sZEB2MC4zMi4wIiwiZGlnZXN0Ijp7InNoYTEiOiI2ZWQ3YWFkNWU4YTM2MDUyZWU1ZjYwNzlmYzkxMzY4ZTM2MjEyMWY3In19XX19
Index: 1484470
IntegratedTime: 2022-02-22T20:52:42Z
UUID: 12a674a87cc4ef05e6d0ae6b14ec2c2928e7cfe2be08497f3e1c8be8ffcadb93
Body: {
  "IntotoObj": {
    "content": {
      "hash": {
        "algorithm": "sha256",
        "value": "8721d922ba53b8fed8031a5ce64cff0a1ae7241a840dd022e9de8a319d3f91a3"
      }
    },
    "publicKey": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNzVENDQWphZ0F3SUJBZ0lVQUwwd2xhV3AvdzdwYVhnWU1zcDlxTHdqMk1Rd0NnWUlLb1pJemowRUF3TXcKS2pFVk1CTUdBMVVFQ2hNTWMybG5jM1J2Y21VdVpHVjJNUkV3RHdZRFZRUURFd2h6YVdkemRHOXlaVEFlRncweQpNakF5TWpJeU1EVXlOREZhRncweU1qQXlNakl5TVRBeU5EQmFNQk14RVRBUEJnTlZCQW9UQ0hOcFozTjBiM0psCk1Ga3dFd1lIS29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRWF1YXNreXYyOTRaeGJMdFNqNXVyNldQVGRoaXIKeEpuN2x6ZGN6R0lFQkM4Ull6SHFGcXZEcXBKQUFjdWhxWmNWU3pYQmFQczZsRlR6M0dmdjBYeCtsNk9DQVU4dwpnZ0ZMTUE0R0ExVWREd0VCL3dRRUF3SUhnREFUQmdOVkhTVUVEREFLQmdnckJnRUZCUWNEQXpBTUJnTlZIUk1CCkFmOEVBakFBTUIwR0ExVWREZ1FXQkJTZVlPV3ZjdHJRYVk2aWNOUU40ZlVoUUU5V1R6QWZCZ05WSFNNRUdEQVcKZ0JSWXdCNWZrVVdsWnFsNnpKQ2hreUxRS3NYRitqQmlCZ05WSFJFRVd6QlpobGRvZEhSd2N6b3ZMMnQxWW1WeQpibVYwWlhNdWFXOHZibUZ0WlhOd1lXTmxjeTkwWld0MGIyNHRZMmhoYVc1ekwzTmxjblpwWTJWaFkyTnZkVzUwCmN5OTBaV3QwYjI0dFkyaGhhVzV6TFdOdmJuUnliMnhzWlhJd2NnWUtLd1lCQkFHRHZ6QUJBUVJrYUhSMGNITTYKTHk5amIyNTBZV2x1WlhJdVoyOXZaMnhsWVhCcGN5NWpiMjB2ZGpFdmNISnZhbVZqZEhNdmNISnBlV0V0WTJoaAphVzVuZFdGeVpDOXNiMk5oZEdsdmJuTXZkWE10WTJWdWRISmhiREV0WXk5amJIVnpkR1Z5Y3k5emNHbHlaVEFLCkJnZ3Foa2pPUFFRREF3TnBBREJtQWpFQWxvY3EwdWtqWC9ZcUFLbnc3eVo2ZU9RUkRPRkJaeXBEbFB4OEYySXgKWmhvdGN6dlFPdFh6bDN3VEsvODNYTG55QWpFQW9vdjJ0WkJEam9hckYzZTA1Z0JrcVU1M09YeUk0VG9CR0I3NQo4RGQzS3J0RCsyL1hsYWJGWWpuZ3ZybmxBSVZ1Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
  }
}

The good news is that cosign is passing in the correct sha to Rekor search, but Rekor search doesn't seem to be returning any UUID even though we know one exists. Maybe this is also because it's an InToto rekord type, as @vaikas pointed out.

For this to start working, I think we need to:

Set the payload annotation to the entire DSSE envelope in the case of in-toto attestations in Chains (e.g.payload=signature-decoded which is what cosign expects)
Add ability to search by SHA for Intoto records to rekor

Feb 22 '22 22:02 priyawadhwa

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale with a justification. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

May 23 '22 22:05 tekton-robot

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten with a justification. Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with /close with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

Jun 22 '22 22:06 tekton-robot

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen with a justification. Mark the issue as fresh with /remove-lifecycle rotten with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

Jul 22 '22 23:07 tekton-robot

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen with a justification. Mark the issue as fresh with /remove-lifecycle rotten with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Jul 22 '22 23:07 tekton-robot

/remove-lifecycle rotten

Jul 25 '22 22:07 priyawadhwa

/lifecycle stale

Send feedback to tektoncd/plumbing.

Oct 23 '22 22:10 tekton-robot

/lifecycle rotten

Send feedback to tektoncd/plumbing.

Nov 22 '22 22:11 tekton-robot

/close

Send feedback to tektoncd/plumbing.

Dec 22 '22 22:12 tekton-robot

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen with a justification. Mark the issue as fresh with /remove-lifecycle rotten with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

Dec 22 '22 22:12 tekton-robot

chains chains copied to clipboard

cosign verify-blob seemingly does not work with chains attestations.

Expected Behavior

Actual Behavior

Steps to Reproduce the Problem

Additional Info

chains
chains copied to clipboard