Re: goproxy notes

[Katherine Cox-Buday <cox.katherine.e@gmail.com>]

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.

-- 
Katherine