[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: goproxy notes

From: raingloom
Subject: Re: goproxy notes
Date: Sat, 28 Aug 2021 15:38:47 +0200

On Fri, 27 Aug 2021 09:56:30 -0500
Katherine Cox-Buday <> wrote:

> raingloom <> 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.
> >
> >  
> 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!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]