sigstore
Feature: Certificate Caching
Description
We've been running into rate-limits for the public sigstore instance:
unable to sign image: getting signer: getting key from Fulcio: retrieving cert: POST https://fulcio.sigstore.dev/api/v1/signingCert returned 429 Too Many Requests
This is somewhat self-inflicted, since we build and publish a bunch of container images in parallel (sample successful run), but I don't think it's an uncommon issue users will run into.
For gitsign, we made an optional credential cache for avoiding multiple calls to Fulcio. This is disabled by default and if enabled gitsign will use the configured local socket to cache certs it fetches in memory for the lifetime of the cert, and reuse the cert for future signing operations until it expires.
This also has some useful side-benefits like letting users SSH forward the socket to support remote-signing operations.
Nothing in the cache is actually specific to gitsign - the functionality is exposed over a simple RPC API. Would it make sense to add credential-cache support to cosign to allow for client-side caching of certs to avoid Fulcio rate limits?
(Rekor rate limits would be the next concern - I don't think we publish the default rate limits, so I'm not sure how much of a concern this is in practice though 🤷)
cc @jonjohnsonjr
As discussed on Slack, I would recommend we retry requests with backoff rather than add credential caching.
