If you commit and push your credentials, they have been compromised, full stop. This proxy should make no difference to how you handle such a compromise.
Actually it does make a difference. If an employee accidentally commits a CSV file with customer private data, are you actually suggesting that it should not be possible to remove it?
I disagree. The quicker that the personal data can be taken down, the less chance there is for someone to discover that personal data. I can't imagine any large company being comfortable with developers choosing technology that makes this harder to deal with than it should be.
(I am not at all suggesting this scenario is ok, simply asking how one would deal with it if the scenario should occur.)
The go checksum database / go sum / sum.golang.org appends your module name, version, and hash of it's contents into a permanent, immutable, public log as soon the first time it's seen. But sum.golang.org doesn't host any code.
On the other hand, proxy.golang.org re-hosts your module, and you can know that the proxy isn't serving you maliciously or differently than anyone else by verifying it via the public checksum database at sum.golang.org.
I don't believe proxy.golang.org, or any proxy for that matter, is required to host all of the modules and versions listed. It's a dumb caching proxy, and must deal with all of the real world complexities of hosting user content, including taking it down if deemed necessary. So if they need to take something down from the proxy they can, and the checksum database will only permanently retain the hash of the content that makes up the module.
Hmm, you definitely have a point. I was thinking more API tokens and private keys, but confidential data itself falls into a separate category, it cannot be revoked or rolled.
