Document that changing secrets doesn't invalidate the cache about dagger HOT 5 CLOSED

Is it expected in the future that changing secret values will in fact invalidate the cache?

I don't expect we'll change this behavior.

One of the reasons that would make this tricky is that the secret then becomes part of the cache key - this is kinda dangerous, even though the cache key is a sha256 digest. Potentially, it means that a leak of the cache key could allow brute-forcing the secret 😱

Is deleting the container the recommended flow?

At the moment, that's really the only option sadly 😢

I have suggested a new cache subcommand to control cache in the dagger engine: #6260. Is that kind of close to something that you'd be looking for?

from dagger.

Is deleting the container the recommended flow? I'm using this and then rerunning.

hello-dagger$ docker ps --format "{{.Names}}" --filter name='^/dagger-engine-*' | xargs --no-run-if-empty -I"{}" docker rm --force {}
hello-dagger$ export GH_SECRET='{ fix github_token here }'
hello-dagger$ dagger run go run ci/main.go

Is it expected in the future that changing secret values will in fact invalidate the cache?

I'm really loving what dagger is offering and looking forward to using it. Thanks a lot for providing this tool

from dagger.

The exception is when a secret is provided as input to a module with dagger call. Secrets from the CLI have a name that's based on the value.

from dagger.

At the moment, that's really the only option sadly 😢

@jedevc I think invalidating the cache via https://docs.dagger.io/cookbook/#invalidate-cache also works. Unless I'm missing something, I just did a test and when the cache gets invalidated before the With*Secret* calls, the secret gets effectively updated in the subsequent steps.

cc @taylormonacelli

from dagger.

At the moment, that's really the only option sadly 😢

@jedevc I think invalidating the cache via https://docs.dagger.io/cookbook/#invalidate-cache also works. Unless I'm missing something, I just did a test and when the cache gets invalidated before the With*Secret* calls, the secret gets effectively updated in the subsequent steps.

Yes using CACHEBUSTER variable works great, but having to add that explicitly for changing secrets is the problem because now you're always invalidating the cache when secret may have not changed.

from dagger.