[ignaloidas]

If the proxy changes a new version of a package, when you update it, there's no way to detect it since it fetches through the cache anyways, so a poisoned sum will be added to sumdb, and anyone who isn't fetching their packages through Google's proxy will get told that whatever they're using is trying to trick them.

[teeray]

> anyone who isn't fetching their packages through Google's proxy will get told that whatever they're using is trying to trick them.

That is exactly the detection of a poisoned module in the ecosystem. It would break builds, issues would get filed, and a new version would be released (and the malicious party may not be so lucky this time since it’s trust on anyone’s first use).

[ignaloidas]

Considering how few people do so, I'm fairly certain it would take more than a month for somebody to catch that.

But I guess it's also fairly easy to test it: just serve a slightly different version to the google's go mirror (by the user agent), and see how long until somebody complains to you about it.

[morelisp]

> how few people do so

I think every company I know of with private Go modules (6-8 or so?) is running a module proxy, which will detect this. The several times we've detected this it's always been within 2-3 days of the upstream mistake. When I go to report a bug we're not always the first either.

[morelisp]

> anyone who isn't fetching their packages through Google's proxy will get told that whatever they're using is trying to trick them.

No, the error message you get is neutral about which side might be wrong - it says "verifying module: checksum mismatch" and "This download does NOT match the one reported by the checksum server." (I've seen it a lot because it also appears when module authors rebase, which a small but surprisingly high number do...)

[lanstin]

Wow, that is shocking. There is never a reason to rebase a public git repo, except maybe credentials leak in the past.

[adityasaky]

Even then, you want to revoke those credentials rather than try to wipe it from history, no?

[lanstin]

That is what I think but security people want both.

[adityasaky]

Strange, I hadn't come across that before. Not sure what they're trying to achieve, deny they ever had a leak?

[lanstin]

Third party security consultants, following a check list.