Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Also I would like to bring up since JFrog's module proxy, GoCenter was publicly hosted first, they will have more than likely been first to host a module version. That means you are now open to the situation where someone uploaded v1.0 of a module to Go Center, and v1.0 of a module to Google's Mirror, and they contain different code.

I am not sure how the Go team plans to handle this, but the only obvious solution would be for Google's proxy to reach out to GoCenter first to see if they have a copy of a specific version, download and cache, and serve that. Does anyone know if that happens?



Why would two versions - specifically tied to a given commit - of say "v1.2.3" contain different code?


Well you mentioned it in your comment, tags are not specific commits. Go Modules standardize around SemVer, and fallback to hashes only when it needs to. The reality is anyone can git push -f and change what a tag points to currently.

So the scenario goes like this: 1. Someone requests a module from GoCenter that is currently not in it's caches. 2. Gocenter downloads the requested version v1.2.3, and stores that. 3. Bad/Careless/Ignorant/Evil (depending on circumstances, I guess) git push -f's 4. Module is requested in Google's module proxy, which now loads a "v1.2.3" into it's local caches, but it contains different code now than "v1.2.3" of GoCenter

Outside of git push -f, there are other hacky techniques you can use to "update" the code a tag points to.


Hmmm, maybe my understanding of tags is incorrect.

When I tag something in git, that is for a specific commit isn't it?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: