goproxy notes

goproxy notes

[raingloom]

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

Re: goproxy notes

[Katherine Cox-Buday]

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

Re: goproxy notes

[raingloom]

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!