Re: goproxy notes

[raingloom <raingloom@riseup.net>]

On Fri, 27 Aug 2021 09:56:30 -0500
Katherine Cox-Buday <cox.katherine.e@gmail.com> wrote:

> raingloom <raingloom@riseup.net> 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
> server.
> 
> 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
> reproducibility.
> 

Guix wins again. UwU
Thanks for looking into it!