Live data from Hacker News

Google has been DDoSing Sourcehut for over a year

drewdevault.com

151–160 of 225 posts

Re: Google has been DDoSing Sourcehut for over a year

#151

Earlier quoted context omitted.

They didn't brush him off. They gave him an immediate workaround, which --- contra some messages on this thread --- did not entail making sr.ht unusable for Go projects. At the time he posted this, he had not taken the Go team up on that workaround; doing so appears to involve only DeVault saying "go ahead" to the Go team.

> They didn't brush him off. I disagree, the "for boring technical reasons..." is as close to a brush-off as I can see. This is a technical issue tracker, why not be open and honest about the reasons? I feel like these days people just seem to take it on faith that "Oh, it's Google, surely they know best when they say it's a mysterious technical issue that's too hard to solve". Also, banning someone from the issue tr…

This is how every issue tracker works. It takes time to explain things (and more time to generate all the facts needed to put together an accurate explanation). What matters is that they got him a workaround --- apparently, almost immediately. He hasn't taken them up on it; it's unclear why.

There's no indication I can see that DeVault's "banning" from the issue tracker has anything to do with any of this.

There's always going to be some standard the Go team (or the Rust team, or the Clojure team, or the Scala team, or any other team down the line until you just decide to do your own language and hope for the day you get to occupy the gratifying job of fielding these kinds of tickets) doesn't meet, for someone on some message board somewhere.

Re: Google has been DDoSing Sourcehut for over a year

#152

Earlier quoted context omitted.

> They didn't brush him off. I disagree, the "for boring technical reasons..." is as close to a brush-off as I can see. This is a technical issue tracker, why not be open and honest about the reasons? I feel like these days people just seem to take it on faith that "Oh, it's Google, surely they know best when they say it's a mysterious technical issue that's too hard to solve". Also, banning someone from the issue tr…

This is how every issue tracker works. It takes time to explain things (and more time to generate all the facts needed to put together an accurate explanation). What matters is that they got him a workaround --- apparently, almost immediately. He hasn't taken them up on it; it's unclear why. There's no indication I can see that DeVault's "banning" from the issue tracker has anything to do with any of this. There's al…

[deleted]

Re: Google has been DDoSing Sourcehut for over a year

#153
post #11
post #9

Wait... Why not black hole them? Make it their problem and they'll eventually do the correct thing.

" I can’t blackhole their IP addresses, because that would make all Go modules hosted on git.sr.ht stop working for default Go configurations (i.e. without GOPROXY=direct)"

This seems like a solution, right? People will ask why their stuff is breaking, and either drop Go for being unreliable or get google to fix it's behavior. Win/win

Re: Google has been DDoSing Sourcehut for over a year

#154

Earlier quoted context omitted.

That doesn’t seem like a solution at all and is actually kind of punative as that would make srht bad for hosting go. I think this is just an example of Google being a jerk and not caring enough to do proper software engineering. Go seems really interesting but I have avoided using it because it’s so tied to Google. And I don’t trust Google to make good decisions for developers or users.

Can you articulate why it isn't a solution, and how it would be punitive? There are people on this thread who appear to believe Google's workaround would mean that repositories hosted on sr.ht would be unusable as Go modules, which is not at all the case.

drew articulated it very well why google's offer doesn't help at all.

https://github.com/golang/go/issues/44577#issuecomment-85693...

A full git clone just to DDOS a hoster to check if the user-experience is still first-class, and filling a proxy is not an acceptable solution for a module hoster who has the pay the hosting bills by himself.

If they want to know if their proxy is still uptodate, a cheap latest change request 8x/hour would be appropriate.

> Have you considered the robots.txt approach, which would simply allow the sysadmin to tune the rate at which you will scrape their service? The best option puts the controls in the hands of the sysadmins you're affecting. This is what the rest of the internet does.

> Also, this probably isn't what you want to hear, but maybe the proxy is a bad idea in the first place. For my part, I use GOPROXY=direct for privacy/cache-breaking reasons, and I have found that many Go projects actually have broken dependencies that are only held up because they're in the Go proxy cache — which is an accident waiting to happen. Privacy concerns, engineering problems like this, and DDoSing hosting providers, this doesn't looks like the best rep sheet for GOPROXY in general.

Re: Google has been DDoSing Sourcehut for over a year

#156

Earlier quoted context omitted.

Why not just return a 429 (Too Many Requests) if the specific repo has been requested by google not too long ago ? (e.g. 1 hour earlier or). It's a standard response code, and with a bit of luck google will scale the requests accordingly. If not, this will still allow the proxy to operate properly without burning too much server resources. (I understand that this may leave some customers unhappy since the proxy may b…

> It's a standard response code, and with a bit of luck google will scale the requests accordingly. Google already says in the comments [1] that it would be "a fair bit of work" for them to read the standard robots.txt for "boring technical reasons". I would not necessarily rely on them to respect HTTP 429 either. In fact, given the facts at hand with the current situation, I would guess that they probably wouldn't h…

> "a fair bit of work" for them to read the standard robots.txt for "boring technical reasons".

that's embarrassing. What other reasons should there ever be?

Stop taking their money, stop using their shit. Turn your attention to where it's beneficial.

Re: Google has been DDoSing Sourcehut for over a year

#157
post #10

If it were me, and I wasn't willing to just block the traffic, I might just set a 128 kbps limit on it and call it a day[1]. Eventually, the other side will figure out that their fetchers are all backed up and work out how to do their job without burning so much bandwidth. [1] Yeah, that can be a bit of a pain to setup depending on the server settings, but some people have to pay for bandwidth and server resources, s…

Or you could mess with a random percentage of the requests: tarpit them, drop random packets, reply with malformed answers etc. If you keep the percentage low they might have a fun time debugging :)

While amusing, responding in this way seems overly antagonistic/escalatory. i.e. the behaviour of a poor citizen of the web.

It also would be likely to result in an increased number of requests?

Drew's actions so far (as far as I can tell) are not only inoffensive/reasonable but overtly good-willed and presumably result from a considerable amount of effort.

Re: Google has been DDoSing Sourcehut for over a year

#158
post #11

Earlier quoted context omitted.

" I can’t blackhole their IP addresses, because that would make all Go modules hosted on git.sr.ht stop working for default Go configurations (i.e. without GOPROXY=direct)"

This seems like a solution, right? People will ask why their stuff is breaking, and either drop Go for being unreliable or get google to fix it's behavior. Win/win

Or switch hosting providers. Lose.

Re: Google has been DDoSing Sourcehut for over a year

#160
post #120

Earlier quoted context omitted.

Smarter than your average proxy, but apparently dumb enough it doesn't actually cache at all, according to the reports.

Obviously it does cache, because the simplest solution offered by the Go team is to exclude sr.ht from the cache refresh that DeVault is complaining about, and he hasn't taken them up on that.

If it's such a widespread problem that there is a process to exclude domains from the cache refresh, doesn't that point to it being an issue that should be fixed by the party responsible instead of everybody else separately?
Post reply on HN