16 votes

Google has been DDoSing SourceHut for over a year

9 comments

  1. [7]
    umbrae
    Link
    I’m not familiar with the go ecosystem or source hut but this dude appears to be complaining about an additional 30 requests per minute?

    I’m not familiar with the go ecosystem or source hut but this dude appears to be complaining about an additional 30 requests per minute?

    10 votes
    1. [2]
      Diff
      Link Parent
      And calling it DDoSing, yes. What's worse, he was given and flatly ignored a solution, that the other person took. The offer's still open even, and yet he's writing blog posts complaining about it...

      And calling it DDoSing, yes. What's worse, he was given and flatly ignored a solution, that the other person took. The offer's still open even, and yet he's writing blog posts complaining about it a year later. I really admire his technical achievements but takes like this are unfortunately very characteristic of Drew.

      13 votes
      1. Greg
        Link Parent
        Oh wow, I didn’t even catch that nuance. I read the article and it sounded like he was being a misleading, crotchety ass about the whole situation but that golang were also refusing to engage....

        Oh wow, I didn’t even catch that nuance. I read the article and it sounded like he was being a misleading, crotchety ass about the whole situation but that golang were also refusing to engage. Having now read the git issue as well, it turns out they pretty quickly said:

        In the meantime, if you would prefer, we can turn off all refresh traffic for your domain while we continue to improve this on our end. That would mean that the only traffic you would receive from us would be the result of a request directly from a user. This may impact the freshness of your domain's data which users receive from our servers, since we need to have some caching on our end to prevent too frequent fetches.

        Maybe not perfect, but exactly the kind of immediate patch that’s needed when large complex systems cause problems and a full overhaul will take time.

        There’s even an explicit invitation on there for him to email if needed because he’s been banned from that issue tracker.

        10 votes
    2. [4]
      streblo
      Link Parent
      30 full clones per minute...

      30 full clones per minute...

      12 votes
      1. [3]
        Diff
        (edited )
        Link Parent
        I'm not 100% confident it is full clones. There's this comment given when Drew first asked about clones vs fetches that says: I'm far, far from being a git expert but scanning through all...

        I'm not 100% confident it is full clones. There's this comment given when Drew first asked about clones vs fetches that says:

        For example, go mod download module@version (which is what proxies are expected to use to fetch a module at a particular version), isn't guaranteed to perform a single HTTP request. It may do things like first request a list of all the tags of that module, then look for the go.mod file or other metadata, then do a shallow fetch to get the contents.

        From proxy.golang.org's perspective, we shell out work to the go command, and it's up to the go command to decide how best to retrieve the information and pass it back to us.

        I'm far, far from being a git expert but scanning through all instances of Run(r.dir, "git", in the relevant file that would be called by go mod download, it seems to do everything it can to avoid fetching more than it has to into the local cache.

        I am not 100% confident it isn't full clones, because there's a line immediately after that first quote that I'm failing to put into context:

        So the idea of keeping a cache of clones around isn't practical, nor would it help the go command.

        I believe it's fine because the go command itself is generating its own cache. But there's also comments like this one:

        We did consider caching clones, but it has security implications and adds complexity, so we decided not to. It is certainly not trivial to do and not something we are likely to do based on this issue.

        Meanwhile, on a completely different issue elsewhere, gentoo struggled with getting full clones of a 900MB repo pulled down, but that's cause they got caught in a random sample for regression testing. The fact that they didn't have excessive traffic outside of the time periods where testing was happening kinda tells me that shallow fetches are actually what's happening in the normal case.

        It'd really be helpful if Drew had mentioned the actual amount of data that was being pulled off his server.

        2 votes
        1. [2]
          streblo
          Link Parent
          This is the comment from the same issue which leads me to believe they are or were doing full cones, but I guess I can't be 100% sure either as it's a year old at this point.

          This is the comment from the same issue which leads me to believe they are or were doing full cones, but I guess I can't be 100% sure either as it's a year old at this point.

          2 votes
          1. Diff
            Link Parent
            There's a lot of confusing, conflicting information. 4GB across 500 requests is just more than you can cough up from a fetch for a module made/used by exactly one person. And yet when Gentoo went...

            There's a lot of confusing, conflicting information. 4GB across 500 requests is just more than you can cough up from a fetch for a module made/used by exactly one person. And yet when Gentoo went back and looked at their traffic history, they saw fetches before and outside of getting slammed by the regression tests.

            I'm not sure how to square everything with everything else short of a hopefully-resolved bug in the proxies, maybe Drew would be willing to offer up details on the size of the requests he's seeing.

            2 votes
  2. [2]
    Weldawadyathink
    Link
    This line bothered me possibly more than it should have: Maybe don't lie about the reasons you want a distro to change a default config? Maybe just give your actual reason, and they might be more...

    This line bothered me possibly more than it should have:

    I tried to advocate for Linux distros to patch out GOPROXY by default, citing privacy reasons, but I was unsuccessful.

    Maybe don't lie about the reasons you want a distro to change a default config? Maybe just give your actual reason, and they might be more receptive? Privacy is a good goal, absolutely, but hiding your true intentions seems like a bad way to go. It seems like the author wanted this to change and came up with an excuse that he thought people wanted to hear. This is deceit. And his reason for wanting the change is actually a good one. It (arguably) places undue burden on server operators hosting GO projects. Maybe just tell the maintainers this and ask them to change the default config instead of trying to deceive them?

    9 votes
    1. FlippantGod
      Link Parent
      No, that bothered me a lot as well. It is a valid reason to put forward, even if it will be declined by the distros, but he basically went looking for a reason to have it patched out even if he...

      No, that bothered me a lot as well. It is a valid reason to put forward, even if it will be declined by the distros, but he basically went looking for a reason to have it patched out even if he also felt it was a privacy issue.

      I'd like to look at the issues in question, but I don't see any links and I'm not that dedicated, lol. So I guess I'll take his word that he was being disingenuous.

      2 votes