4 ms·

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 w

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.

morelisp 4y ago
> 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 4y ago
  Wow, that is shocking. There is never a reason to rebase a public git repo, except maybe credentials leak in the past.
  - adityasaky 4y ago
    Even then, you want to revoke those credentials rather than try to wipe it from history, no?
    - lanstin 4y ago
      That is what I think but security people want both.
      - adityasaky 4y ago
        Strange, I hadn't come across that before. Not sure what they're trying to achieve, deny they ever had a leak?
        lanstin 4y ago
        Third party security consultants, following a check list.
teeray 4y ago
> 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 4y ago
  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 4y ago
    > 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 4y ago

> 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 4y ago
Wow, that is shocking. There is never a reason to rebase a public git repo, except maybe credentials leak in the past.
- adityasaky 4y ago
  Even then, you want to revoke those credentials rather than try to wipe it from history, no?
  - lanstin 4y ago
    That is what I think but security people want both.
    - adityasaky 4y ago
      Strange, I hadn't come across that before. Not sure what they're trying to achieve, deny they ever had a leak?
      - lanstin 4y ago
        Third party security consultants, following a check list.

teeray 4y ago

> 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 4y ago
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 4y ago
  > 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.