chains
chains copied to clipboard
cosign verify-blob seemingly does not work with chains attestations.
Expected Behavior
The tutorial here to work.
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
orkubectl 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%
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
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.
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.
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
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.
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.
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.
@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.
/remove-lifecycle rotten
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.
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.
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.
@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.