[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: goproxy notes
Re: goproxy notes
Sat, 28 Aug 2021 15:38:47 +0200
On Fri, 27 Aug 2021 09:56:30 -0500
Katherine Cox-Buday <email@example.com> wrote:
> raingloom <firstname.lastname@example.org> writes:
> > do we depend on this? if yes, it might be a good idea to disable the
> > proxy in the importer.
> > sorry, i don't have time to look into it myself right now, so i'm
> > dumping it here.
> > https://drewdevault.com/2021/08/06/goproxy-breaks-go.html
> Thanks a lot for bringing this up.
> The Go importer has a flag for specifying the proxy server to check
> (Google's is used by default), but this is only used to fetch
> preliminary information about a module, i.e. =go.mod=, the repo's URL,
> and what the proxy thinks is the latest version. The VCS type, VCS
> URL, and actual source code are fetched from the module's defined
> source (i.e. github, etc.).
> It would have been much easier on everyone involved with writing the
> Go importer to just fetch the package from the proxy, but we had the
> foresight to realize it would cause this exact issue: centralization
> on a single service owned by a single company. Since we did not do
> that, a brief scan of our Go packages suggests that all of them are
> fetching source from their respective repositories, and not a proxy
> As I understand it, Guix builds cannot reach out to the network, so
> there is no risk of leaking metadata to Google via invocation of Go
> commands. Further, our current Go build system does not even use
> modules (this needs to change).
> I think this addresses all the points in this blog post. Overall, I
> think Guix is very well positioned because of how we generate Go
> packages, how our build system works, and how Guix emphasises
Guix wins again. UwU
Thanks for looking into it!