-
Notifications
You must be signed in to change notification settings - Fork 546
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Signing images by digest that don't exist yet #1905
Comments
I have this exact use case. I believe not having the signature available for a brief moment is as bad as not having the signature at all since this time period could overlap with the pod scheduling thus leading to the unsigned images being used by systems unless you have something in place to prevent this. This is okay if you control both the image itself and downstream systems. however, this is not easy if you don't control the downstream dependents. |
We should definitely fix this. |
I'd be willing to fix it if I am given the proper instructions. I am not familiar with the codebase at all but already familiar with gccr. |
FYI @imjasonh is probably a good person to give some guidance here; he's OOO this week but will be back next week. Give him a few days to catch up and then maybe ping this issue. |
@puerco says #1616 unintentionally removed this ability, and we should add it back. AIUI this means using If we're concerned about the race that introduces, we can do something smarter and more involved with @thesayyn if you're interested that would be great. The APIs should all feel very familiar coming from ggcr 😄 |
@imjasonh Definitely. I'll start by understanding what each of these APIs does. Thanks for the pointers. |
@imjasonh I have some questions here; 1- What if the |
I had the same issue and wanted to summarize the discussion we had with sigstore slack channel:
Workarounds suggested:
thanks @mattmoor and @jonjohnsonjr for clarification. I would really like to contribute to documenting these limitations if someone can point me around and get into specifics of the differences in the digest generation by clients that make this hard to achieve. |
I haven't been able to figure out what the behavior should be. I am still interested but got questions. |
Resolve sigstore#1905 Signed-off-by: Paolo Mainardi <[email protected]>
Just tried to open a PR to address this: #2824 |
🎁 This feature allows `cosign` to sign a digest that doesn't exist yet, to support scenarios such as signing an image prior to pushing it. This adapts the ideas from the two prior approaches, which were closed by stale-bot. Fixes: sigstore#1905 /kind feature
🎁 This feature allows `cosign` to sign a digest that doesn't exist yet, to support scenarios such as signing an image prior to pushing it. This adapts the ideas from the two prior approaches, which were closed by stale-bot. Fixes: sigstore#1905 /kind feature Signed-off-by: Matt Moore <[email protected]>
🎁 This feature allows `cosign` to sign a digest that doesn't exist yet, to support scenarios such as signing an image prior to pushing it. This adapts the ideas from the two prior approaches, which were closed by stale-bot. Fixes: sigstore#1905 /kind feature Signed-off-by: Matt Moore <[email protected]>
🎁 This feature allows `cosign` to sign and attest a digest that doesn't exist yet, to support scenarios such as signing an image prior to pushing it. This adapts the ideas from the two prior approaches, which were closed by stale-bot. Fixes: sigstore#1905 /kind feature Signed-off-by: Matt Moore <[email protected]>
stale-bot got the two attempts at this. I took a crack at this blending the approaches, fixing |
🎁 This feature allows `cosign` to sign and attest a digest that doesn't exist yet, to support scenarios such as signing an image prior to pushing it. This adapts the ideas from the two prior approaches, which were closed by stale-bot. Fixes: sigstore#1905 /kind feature Signed-off-by: Matt Moore <[email protected]>
🎁 This feature allows `cosign` to sign and attest a digest that doesn't exist yet, to support scenarios such as signing an image prior to pushing it. This adapts the ideas from the two prior approaches, which were closed by stale-bot. Fixes: sigstore#1905 /kind feature Signed-off-by: Matt Moore <[email protected]>
🎁 This feature allows `cosign` to sign and attest a digest that doesn't exist yet, to support scenarios such as signing an image prior to pushing it. This adapts the ideas from the two prior approaches, which were closed by stale-bot. Fixes: sigstore#1905 /kind feature Signed-off-by: Matt Moore <[email protected]>
* Feature: Allow cosign to sign/attest digests before they are uploaded. :gift: This feature allows `cosign` to sign and attest a digest that doesn't exist yet, to support scenarios such as signing an image prior to pushing it. This adapts the ideas from the two prior approaches, which were closed by stale-bot. Fixes: #1905 /kind feature Signed-off-by: Matt Moore <[email protected]> * Apply suggestions from code review Co-authored-by: Jon Johnson <[email protected]> Signed-off-by: Matt Moore <[email protected]> --------- Signed-off-by: Matt Moore <[email protected]> Signed-off-by: Matt Moore <[email protected]> Co-authored-by: Jon Johnson <[email protected]>
Description
It should be possible to sign an image specified by digest that doesn't (yet) exist in the registry, so long as the user has permission to push to the repository. As an example, I should be able to
cosign sign registry.biz/myuser/image@sha256:abcdef
even if no image with that digest exists yet.Signing
registry.biz/myuser/image:tag
should still require that that tag exists, becausecosign
needs to be able to lookup the digest the tag points to. Theregistry.biz/myuser
repository also must exist, and be accessible to the user, because that's where we'll push the signature.Pre-signing images because an image build tool can write a signature to the repository before the image being signed is pushed, for example if I enforce a policy that only signed images can exist in my registry. Signing after pushing introduces a race condition, especially if signing fails for some reason (e.g., I close the OIDC browser tab and walk away), leading to unsigned images.
This used to work in a previous version of
cosign
, but seems to have regressed (possibly #1616 @puerco?). If we decide to fix this, we should introduce a test that guards against future regressions. Re #1616 we should also make sure that you can sign the same non-existent digest multiple times successfully.Currently:
The text was updated successfully, but these errors were encountered: