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.
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.
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.
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.