Skip to content

Cache keys can be hashed

What does this MR do?

When FF_HASH_CACHE_KEYS is enabled, cache keys are hashed.

The plain cache keys are still preserved:

  • in a file metadata.json alongside the cache.zip on local caches
  • as blob metadata for distributed caches

The above mentioned metadata is still created/managed when FF_HASH_CACHE_KEYS is disabled.

Why was this MR needed?

To not be vulnerable against malicious cache keys, which could allow users to extract or overwrite protected caches, the cache keys are hashed now.

What's the best way to test this MR?

  1. setup runner with FF_HASH_CACHE_KEYS enabled, and with distributed caching
    • azure
    • s3
    • s3v2
    • gcs
    • gcsv2
  2. Run jobs with caching, with and without the following:
    • different policies (pull vs. push vs. pull-push)
    • different/multuiple fallback keys
    • with CACHE_FALLBACK_KEY
  3. Ensure the caching works:
    • cache artifacts are successfully pulled / pushed
    • the cache key for an artifact is available
      • in a local file metadata.json
      • as part of the blob's metadata in the clouds

What are the relevant issue numbers?

related: gitlab-org/gitlab-runner#38349

Edited by Hannes Hörl

Merge request reports

Loading