On Fri, 27 Aug 2021 09:56:30 -0500 Katherine Cox-Buday <cox.katherin...@gmail.com> wrote:
> raingloom <raingl...@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!
