3 comments
hellerve4 days ago
i’d argue against just saying "An adversary with write access to files on your machine has better things to do than tamper with your Go cache — by rational choice, they’ll steal your secret keys instead." because that’s only true if I have access to both. If I only have access to the cache, I might use that capability to get a chain into the next level going etc.
I’m not saying that "a poisoned Go cache" should necessarily be part of everyone’s threat model, but I’d also not just dismiss it by saying "well, it requires disk access". Either might be wrong, depending on your situation.
lukasschwab3 days ago
Didn't mean to dismiss it. I think it's worth reasoning about! e.g. the CI example — in a build cache shared between ephemeral instances, cache poisoning can smuggle malicious behavior from untrusted environments to trusted ones. You're right.
hellerve2 days ago
Didn’t necessarily think you were saying that, but everyone’s looking for an easy excuse with security problems, so best we can do is hit them with the ol' “it depends" :)
Great article, by the way, thank you!
Read the full thread on Hacker News →
Related stories
- DEV Community · 0 points · 10 days ago
- Covert Caches: When Is a Cache, a Cache?parallelprogrammer.substack.comHacker News · 2 points · 10 days ago
- Cache Invalidation Simulatorinduction.aiHacker News · 2 points · 1 day ago
- DEV Community · 6 points · 7 days ago
- Hacker News · 1 points · 4 days ago
- (KV) Cache Rules Everything Around Mecompleteskeptic.comHacker News · 3 points · 6 days ago