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

When creating volume caches, incorporate "pack volume key" to avoid name collisions #48

Merged
merged 4 commits into from
Jul 16, 2024

Conversation

natalieparellano
Copy link
Member

Fixes buildpacks/pack#2224

(still has some TODOs, but there is enough to get the direction)

Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
if err != nil {
return nil, err
}
sum := sha256.Sum256([]byte(imageRef.Name() + volumeKey)) // TODO: investigate if there are better ways to do this
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd appreciate some feedback on this aspect of it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I presume using an md5sum of the actual volume is too expensive?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, and the value would also change over time as stuff gets added and removed from the volume. We need something that is deterministic with the image name + key

@natalieparellano natalieparellano changed the base branch from main to security-review July 10, 2024 14:22
@natalieparellano natalieparellano deleted the branch main July 10, 2024 14:45
@natalieparellano natalieparellano changed the base branch from security-review to main July 10, 2024 14:49
Copy link
Member

@AidanDelaney AidanDelaney left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good


// first, look for key in env

foundKey = os.Getenv(EnvVolumeKey)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be one of the pack client options? Then the cobra side of the processing can find the env var or default it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe? But, we don't have a corresponding flag for it - it's all env var based. I would say this is pretty similar to how we have DefaultRegistry() and DefaultConfigPath() sprinkled throughout the code. I didn't want to have to pass the value all the way from commands -> client.BuildOptions -> down through build.LifecycleOptions when we could just read it at the point where it's needed.

if err != nil {
return nil, err
}
sum := sha256.Sum256([]byte(imageRef.Name() + volumeKey)) // TODO: investigate if there are better ways to do this
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I presume using an md5sum of the actual volume is too expensive?

pkg/cache/volume_cache.go Show resolved Hide resolved
@@ -24,7 +27,7 @@ func TestVolumeCache(t *testing.T) {
color.Disable(true)
defer color.Disable(false)

spec.Run(t, "VolumeCache", testCache, spec.Parallel(), spec.Report(report.Terminal{}))
spec.Run(t, "VolumeCache", testCache, spec.Sequential(), spec.Report(report.Terminal{}))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose this is required because we are writing to disk the volume-keys.toml, I am ok with it because I think these tests are not going to increase the CI too much but if it is possible to keep it as parallel it will be awesome

@jjbustamante
Copy link
Member

jjbustamante commented Jul 15, 2024

I am ok with this change, my only doubt was if we are doing this:

  • PACK_VOLUME_KEY should be overridden when pack is running in CI (we could warn if this env var is unset and we detect that pack is running in a container as this effectively disables caching).

From the solution proposed.

Copy link
Member

@jjbustamante jjbustamante left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just left a few comments but I am ok with it

@natalieparellano
Copy link
Member Author

Great catch @jjbustamante! I added the warning in 331ac6d

@natalieparellano natalieparellano merged commit 13ca537 into main Jul 16, 2024
11 of 13 checks passed
@natalieparellano natalieparellano deleted the pack-volume-key branch July 16, 2024 14:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Security review: ensure ownership of build and launch caches
3 participants