Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sourcehut will blacklist the Go module mirror

sourcehut.org

Post reply on HN
Print view View original

301–310 of 365 posts

Re: Sourcehut will blacklist the Go module mirror

#301

Post by yamtaddle »

ddevault wrote: post #299
tptacek wrote: post #298

Earlier quoted context omitted.

See, here you just did it again: "muzzle the other party", as if it was causally connected to your disagreement about how the module proxy should work, and not to the abuse you inflicted on members of that community.

I admitted that my comments about EFAIL -- four years ago now -- were in the wrong, and apologized for them. Unless you're going to argue that this issue should justify consuming 70% of my system's network bandwidth without recourse, move on. In the interest of not feeding the trolls, I think I can safely stop engaging with you on this thread. Or maybe on any thread -- you and I never seem to have a productive conver…

> In the interest of not feeding the trolls, I think I can safely stop engaging with you on this thread. Or maybe on any thread -- you and I never seem to have a productive conversation on this website.

HN would be so very much more pleasant with ignore-lists.

Re: Sourcehut will blacklist the Go module mirror

#303

Post by WorldMaker »

mmis1000 wrote: post #73
winterqt wrote: post #16

Earlier quoted context omitted.

Or, as mentioned in the post, why they don't do a shallow clone if they have to fetch it every time for whatever reason. Seems like a weird decision either way.

Yep, a shallow clone is enough to get the latest version. And you can even filter the tree to make the download size even smaller given you only want the hash but not the contents (if the git server supports this feature) A checkout with this can literally clone nothing but hash git clone --depth=1 --filter=tree:0 --no-checkout https://xxxx/repo.git cd repo git log

People using Go modules should be using git tags, right? They should have at least one hash already that should be infinitely cacheable, the tag commit.

Of course, I have seen alleged examples of Go modules using tags like branches and force pushing them regularly, but that kind of horror sends shivers down my back, at least, and I don't understand why you'd build an ecosystem supporting that sort of nonsense and which needs to be this paranoid and do full repository clones just for caching tag contents. If anything: lock it down more by requiring tag signatures and throwing errors if a signed tag ever changes. So much of what I read about the Go module ecosystem sounds to me like they want supply chain failures.

I don't understand the Go ecosystem.

Re: Sourcehut will blacklist the Go module mirror

#304

Post by throwaway894345 »

saurik wrote: post #271
throwaway894345 wrote: post #103

Earlier quoted context omitted.

Pretty sure virtually every big tech company does the same thing, because they have to integrate a bunch of languages, target any arbitrary platform/architecture tuple, and support use cases like code generation and so on. There aren't any good solutions to this problem that don't require teams of people to maintain--the best in class open source solutions seem to be Bazel and Nix and these are beyond my skill to man…

Everyone ends up having to do this kind of stuff, and so the best tools are ones that take this in stride and make it easier to pull off even if it is at the expense of more pain for trivial project; and like, if you are going to try to build a baby version of the tool for beginners, you probably aren't the right person to even figure out what is required of that tool if you wouldn't normally use it.

> Everyone ends up having to do this kind of stuff, and so the best tools are ones that take this in stride and make it easier to pull off even if it is at the expense of more pain for trivial project

I disagree. Lots of projects will never need support for multiple languages, code generation, targeting a vast array of platforms and architectures, etc and for those that do, there are workarounds that are a lot less painful than Bazel or Nix. I can go a looong ways with `go build` and some CI jobs before the pain of Bazel or Nix pay off. Basically, I don't think the "trivial projects vs everyone else" is a very good taxonomy, but rather it's "'approaching FAANG scale' vs everyone else".

If you're in the "approaching FAANG scale" group, then yeah, Bazel probably makes sense. For everyone else language-specific tools cobbled together with CI really is the least bad solution (and by a pretty big margin in my experience).

Re: Sourcehut will blacklist the Go module mirror

#305

Post by sidewndr46 »

cbrozefsky wrote: post #102
tssva wrote: post #94

Earlier quoted context omitted.

There is a refresh exclusion list which you can request your site to be added to. The proxy will continue to process requests for modules from your site but will not perform the automatic refresh which caused issues for Sourcehut. The Go team extended an offer to add Sourcehut to the list if a request to do so was made. The request never came and instead Sourcehut blocked the proxy.

"Opt out of me DoSing" you is not legit behavior -- especially when the victim has raised it with you multiple times, suggested fixes, and you have then blocked them from communicating in your issue tracker. That's some really entitled thinking on the part of the Go team at Google, and it's sad to see people stanning for them.

They should have them add a file to their web service at a path of "/i_want_to_live.txt" to indicate not to DoS the server.

Re: Sourcehut will blacklist the Go module mirror

#306

Post by throwaway894345 »

pjmlp wrote: post #294
throwaway894345 wrote: post #248

Earlier quoted context omitted.

Pity that people still argue as though "feature rich" is some unmitigated good. :)

If it wasn't, Go wouldn't have gotten newer features.

Obviously this isn't true, it only indicates that Go didn't pick exactly the right set of features at inception (and of course, no one claimed it did).

Re: Sourcehut will blacklist the Go module mirror

#307

Post by tristan957 »

comex wrote: post #27

According to some comments in the linked GitHub issue, including [1] from last May, Drew could have simply asked to be excluded from automatic refresh traffic from the mirror. If I understand correctly, that would still leave traffic from the mirror when it’s acting as a direct proxy for someone’s request, but that is traffic that would be going to sr.ht regardless. For some reason he did not do this and instead chos…

Should every person that hosts an instance of SourceHut, Gitea, or Forgejo have to opt-in to this? That just doesn't scale at all. Drew is standing up for all independent hosters as much as he is standing up for his own business interests.

Re: Sourcehut will blacklist the Go module mirror

#308

Post by rakoo »

rsc wrote: post #245
eadmund wrote: post #229

Earlier quoted context omitted.

This reminds me a bit of a disfunctional relationship: clearly Sourcehut wants Google to stop DDoS their servers; clearly Google don’t actually want to DDoS Sourcehut, but Sourcehut also doesn’t want to ask Google to stop, and Google also want to be asked to stop. And so nothing gets done. The question is who will swallow their pride first: Sourcehut or Google.

This isn't true. Sourcehut reported a bug, and since the bug is somewhat involved to fix entirely, we asked what the impact of the bug is to them and offered to make a custom change for the site in the interim. The impact matters: the appropriate response is different for "I saw this in my logs and it looks weird but it's not bothering me" versus "this is causing serious problems for my site". We have been getting mi…

> the appropriate response is different for "I saw this in my logs and it looks weird but it's not bothering me" versus "this is causing serious problems for my site". We have been getting mixed signals about which it is

We have not been reading the same tickets and articles it seems

Re: Sourcehut will blacklist the Go module mirror

#309

Post by [deleted] »

ddevault wrote: post #290
Arnavion wrote: post #288

Earlier quoted context omitted.

The offer in [1] was to email the ML to ask for an exclusion, not to continue discussing the general issue which was still being discussed in the GH issue. And given that they banned him for no reason, he is perfectly in the right to tell them that they should email him instead.

Correct: it was made clear to me in no uncertain terms that the only thing I was allowed to say was "yes" or "no" to this offer.

[deleted]

Re: Sourcehut will blacklist the Go module mirror

#310

Post by nickelpro »

psanford wrote: post #182
rakoo wrote: post #152

Earlier quoted context omitted.

Why should you opt-in to a No-DDOS list ? Why is it not the default ?

You are basically arguing that sr.ht is taking a "principled stand" against google. If that is what they are doing they should just say that and not pretend like there were no other options. I'm ok with saying "google should do better!" But the compromise solution from the Go team seems reasonable to solve the immediate issue in a way that doesn't harm end users. The author should at least address why they have chose…

The author addressed this by way of their by-line
Post reply on HN