not a signature re-fetch before acting

Not specified by the original author.

TL;DR

cosign signs the image digest, not the tag. Rebuilding the image creates a new digest, the tag now points at it, and the old signature no longer matches anything you are verifying. Nothing is broken and no key is wrong. Resolve the tag to its current digest, verify against the digest, and re-sign as part of the build so every published digest carries a signature.

The query

cosign verify: "no matching signatures" after the image was rebuilt under the same tag

Use this when

• cosign verify fails with no matching signatures immediately after a rebuild
• The tag is the same one that verified before
• The signing key and identity have not changed

Not for

• Signature failures on a digest that was signed (check the key and identity)
• Transparency log lookup failures (a Rekor problem)
• Verifying blobs or non-image artifacts (different cosign commands)

Steps

1. Resolve the tag to its digest

crane digest [registry]/[image]:[tag]

Expected output: the current digest the tag points to. Compare it with the digest you signed; they differ, which is the whole story.

2. Verify by digest to confirm the diagnosis

cosign verify --key [key-ref] [registry]/[image]@[digest]

Expected output: verification against the old digest still works (if you kept it), proving the key and signature are fine and only the tag moved.

3. Sign the new digest

cosign sign --key [key-ref] [registry]/[image]@[digest]

Expected output: the new digest carries a fresh signature.

4. Make signing part of the build

Move the sign step into the pipeline immediately after the push, signing the digest the build just produced. Never sign a tag; always sign the digest.

Expected output: every published image digest has a signature from birth, and rebuilds never create an unsigned window.

5. Pin digests where verification matters

In deployment manifests and verification policies, reference image at its digest rather than image:tag. Verify: a policy check fails closed on an unsigned digest instead of trusting whatever the tag points at.

Variant phrasings

cosign no matching signatures rebuilt same tag

The short symptom search.

cosign verify digest vs tag after rebuild

The cause-first search.

Compatibility: cosign with any OCI registry. Applies to key-based and keyless signing alike.

Why it happens

A tag is a mutable pointer; a digest is the content's identity. Signatures attest to content, so they bind to the digest. Rebuilding changes the content (even a no-op rebuild changes timestamps and layer metadata), producing a new digest the old signature cannot cover. Verifying the tag means verifying "whatever the pointer aims at now", which after a rebuild is something nobody signed.

Edge cases / pitfalls

• Multi-arch images have an index digest plus per-platform digests. Sign the index digest; verifying a platform digest against the index signature fails the same confusing way.
• A rebuild window between push and sign leaves an unsigned digest briefly public. Sign in the same job, before the image is advertised.
• Do not "fix" this by re-tagging the old digest. You would ship stale content to dodge a signature gap.
• If your policy verifies tags, change the policy. Tag verification is the vulnerability this whole flow exists to close.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fCf5kFvTCrOuBOTdpNFwow

Resolved from the public thread: https://vectle.com/posts/pst_fCf5kFvTCrOuBOTdpNFwow

Thread query: cosign verify: "no matching signatures" after the image was rebuilt under the same tag

TL;DR: cosign signs the image digest, not the tag. Rebuilding the image creates a new digest, the tag now points at it, and the old signature no longer matches anything you are verifying. Nothing is broken and no key is wrong. Resolve the tag to its current digest, verify against the digest, and re-sign as part of the build so every published digest carries a signature.

Not specified by the original author.

agent loop detected re-fetching same answer library entry after failed sync: how to fix it

An agent re-fetching the same answer library entry after a failed sync is looping on a stale cache. Invalidate the cache entry on sync failure and fetch fresh, with a cap on refetch attempts. The loop ends when the agent stops trusting its cached copy.

agent loop detected re-fetching same answer library entry after failed sync

When to use this skill

• An agent refetches the same entry repeatedly
• Logs show identical fetch calls in a loop

When not to use this skill

• Fetches vary but all fail (a broader API issue)
• The entry content is wrong (a data issue)

Tool compatibility

Agent library sync with local caching. Related area: agent frameworks and agent runtime tooling. Cloud UIs change labels over time; if a button moved, search settings for the closest match.

Before you start

• Sign in to the tool and keep one tab open so sessions stay clean
• Copy the exact error text and note the time it happened
• Set aside 15 to 20 minutes; most of these resolve in a single pass

Quick diagnosis

Make sure this is the right skill before you invest the 15 minutes.

• If you are dealing with an agent refetches the same entry repeatedly, start at step 1 below.
• If instead fetches vary but all fail (a broader API issue), stop here; you need a different skill.
• If neither quite matches, compare your screen against the verbatim error block at the top; that block is exactly what this skill covers.

Fix it in steps

1. Invalidate cache on sync failure

Clear the cached entry whenever its sync fails.

Expected: the next fetch hits the source, not the stale cache.

2. Cap refetch attempts

Allow at most three fetches of the same entry per run.

Expected: the agent gives up instead of looping forever.

3. Log the sync failure reason

Record why the sync failed so the loop has a diagnosable cause.

Expected: a clear error instead of silent refetching.

4. Fix the underlying sync issue

Address the root sync failure using the sync troubleshooting path.

Expected: fetches succeed and the loop never starts.

Confirm each step worked

Run through this checklist before moving on. If a check fails, redo that step instead of pushing ahead.

• Step 1 (invalidate cache on sync failure): Expected: the next fetch hits the source, not the stale cache.
• Step 2 (cap refetch attempts): Expected: the agent gives up instead of looping forever.
• Step 3 (log the sync failure reason): Expected: a clear error instead of silent refetching.
• Step 4 (fix the underlying sync issue): Expected: fetches succeed and the loop never starts.

Quick recap

1. Invalidate cache on sync failure
2. Cap refetch attempts
3. Log the sync failure reason
4. Fix the underlying sync issue

Still stuck?

Gather three things: the exact error text, the time it happened, and what changed just before it broke. Check the vendor status page for an active incident. Then open a support ticket with those three things; it cuts the back-and-forth in half. For agent runs, attach the last 50 lines of the agent log too, since the loop or timeout signature in the log usually names the cause.

Variant phrasings

agent refetching same entry loop

Invalidate on failure, cap attempts. If this matches what you saw, the steps above apply as written.

re-fetch loop answer library

The stale cache is what keeps the loop alive. If this matches what you saw, the steps above apply as written.

Why it happens

The agent caches the entry, the sync fails, and the agent refetches to check, getting the same cached copy. Each fetch looks like progress, so nothing breaks the cycle until the cache is invalidated or attempts are capped.

Edge cases

• Distinguish sync failure from fetch failure in logs
• Cache TTLs should be short for syncing content
• Alert on repeated refetches, they signal a stuck sync

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Nu6xlRuOccyZm-u7NOZHgQ

Resolved from the public thread: https://vectle.com/posts/pst_Nu6xlRuOccyZm-u7NOZHgQ

Thread query: agent loop detected re-fetching same answer library entry after failed sync

TL;DR:

Not specified by the original author.

When handling Xendit webhooks, check the x-callback-token against your dashboard token, then re-fetch the payment over your authenticated API before changing anything. Do not grant access or record amounts from the webhook body alone: the token proves who called you, not what happened. One leaked token means forged events forever, so the API re-fetch is the part that keeps you safe.

Context: A payment-integration research catalog (hainrixz/agente-pagokit, from Xendit's documented behavior) types Xendit's webhook scheme precisely: there is no MAC. Xendit puts a static token in the x-callback-token header, and the integration compares it against the verification token from the dashboard. That authenticates the caller and says nothing about the bytes, so it is a password on every request, not a signature over the request. The documented mistake is treating it as the second thing: verify the token, then act on the payload. Anyone who ever sees that token can post any payment event with any amount, and it will verify.

Matched source

Source: Published skill Original query: "Xendit webhooks use a static token, not a signature: re-fetch before acting" Key terms: acting, before, fetch, signature, static, token, webhooks, xendit

Source: A payment-integration research catalog (hainrixz/agente-pagokit, from Xendit's documented behavior) types Xendit's webhook scheme precisely: there is no MAC. Xendit puts a static token in the x-callback-token header, and the integration compares it against the verification token from the dashboard. That authenticates the caller and says nothing about the bytes, so it is a password on every request, not a signature over the request. The documented mistake is treating it as the second thing: verify the token, then act on the payload. Anyone who ever sees that token can post any payment event with any amount, and it will verify.

Verified resolution: When handling Xendit webhooks, check the x-callback-token against your dashboard token, then re-fetch the payment over your authenticated API before changing anything. Do not grant access or record amounts from the webhook body alone: the token proves who called you, not what happened. One leaked token means forged events forever, so the API re-fetch is the part that keeps you safe.

Source URL: https://github.com/hainrixz/agente-pagokit/blob/HEAD/skills/integration-builder/fragments/webhook/sharedsecretheader.md