Skip to content
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

sigstore image deleting #33

Open
rohanmars opened this issue Sep 15, 2024 · 11 comments
Open

sigstore image deleting #33

rohanmars opened this issue Sep 15, 2024 · 11 comments

Comments

@rohanmars
Copy link

rohanmars commented Sep 15, 2024

Hi there
I happened to notice your cleanup task. It seems to be using a variant of the sigstore that I don't think it accounts for in the ghcr-cleanup-action.

deleting package id: 147574249 digest: sha256:c46a7c3c703da49ee911ad26aa7b50f9832fce2f886989f7ff14ac19fe450970 tag: sha256-f01382b35af6bdb9629002a2e60b5d969f7a5e1cfeaea933453b4cb898ead696.sig

In that case the action doesn't look for the suffix ".sig" so I don't think it would be making the correct association between the parent image and sig image. The usecase it currently accounts for (github attestation action) just uses a tag "sha256-f01382b35af6bdb9629002a2e60b5d969f7a5e1cfeaea933453b4cb898ead696" without the .sig. I think I need to add this usecase.

You might want to hold off further execution until I can validate that.
Rohan

@rohanmars
Copy link
Author

I've added sigstore cosign support to the action: dataaxiom/ghcr-cleanup-action@6448a08 and released it in v1.0.12

 uses: dataaxiom/[email protected]

@bsherman
Copy link
Owner

You might want to hold off further execution until I can validate that. Rohan

@rohanmars thank you very much for noticing! This current use was just personal, but also I was planning to take what I learned to apply in the larger ublue-os org, so I'm glad you caught this issue!

I'll update to the new action and see how it goes.

@rohanmars
Copy link
Author

As you had the 90 day older-than option it limited any impact to older images. In that case the sig images where treated as standalone images so where processed as top level image in the keep-n-tagged count processing. From your recent run it does appear that there are some orphaned sig images (older then 90 days). It would be useful to see how it runs over a few days, assuming you have images which will be included in the 90 day bucket on these new runs.

I'm working on a new delete-orphaned-images option to the cleanup action, which will cleanup sha256-xxxxx images (cosign/referrers) if they don't have their parent anymore. I'll commit that in a few days most likely.

I also added some status progress messages on the manifest loading stage, which gives a better indication that things are processing. I had noticed on another repo which had 5000 images that it appears hung while it was actually doing work. I was happy to see your job finished successfully after 3 hours. The long time is due to the api throttling github enforces.

@rohanmars
Copy link
Author

I also see a weird scenario in your latest log where some of the sig are are not included in the 90 days. That would be an unusual usecase where the image/sig publishing was occurring exactly at the 90 mark. I need to investigate that further and review how the action handles that.

@rohanmars
Copy link
Author

Actually I think the logic is okay after all. But I'll watch your repo over the next few days and check the logs. The extra dangling sig image that was in you last run is likely from running with the older version without cosign support.

In your case that stale sig will eventually get cleaned up with the keep-n-tagged mode. But the new feature I'm adding delete-orphaned-images would also clean it up.

@bsherman
Copy link
Owner

Awesome! I had planned to let this run at least a week or more anyway before I implement it elsewhere.

I'm happy to be your test repo for new features.

@rohanmars
Copy link
Author

That's great, haha

I've just released v1.0.13 which includes a new 'delete-orphaned-images' option, which if set to true will delete the orphaned .sig image. Would be useful to see if that option cleans up your orphaned sig in your registry. It's meant as more of a one time thing. And in your case that sig image would eventually get deleted as it's treated as a standalone image as it has no parent image.

@bsherman
Copy link
Owner

@rohanmars
Copy link
Author

That's great. It looks like it did clean up those orphaned sig images (plus some untagged images that had been pulled into scope).

Looks good.

Thanks!

@bsherman
Copy link
Owner

I'm going to let this run at least another week before I do any more implementation. Keep going with these new features! I love it!

@rohanmars
Copy link
Author

Good plan.
Thanks for this cosign requirement and for testing it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants