Hacker News Reader

Comment by w8rbt | Hacker News Reader

This is probably a dumb question, but here goes... I'm testing go modules with an internal project that uses a private github.com repo. It depends on other public go packages and modules is nice to manage those but the general public will probably never see or want to use this code.

Are modules in private repos impacted by this in any way? Would they show-up in the index somehow?

View on HN

If the private one is the main module, you don't have to do anything, it doesn't get sent anywhere because it's just what's on your disk. Indeed, you can call it "module foo", which is not a go-gettable name.

If you _depend on_ private modules, you need to follow these instructions: https://tip.golang.org/cmd/go/#hdr-Module_configuration_for_...

In any case, private modules never show up in the index, mirror, or checksum database.

...but references to them are stored by google in logs and used per the privacy policy at https://proxy.golang.org/privacy

See here[1]. From what I've gathered, you should set GOPRIVATE appropriately, otherwise the Go Module Mirror(s) and the Go Checksum Database(s) may know that you have a private repo called “github.com/you/very-private”. It could also probably reason about your dependencies a little bit.

[1]: https://tip.golang.org/cmd/go/#hdr-Module_configuration_for_...

Yes, I don't mind if it shows up in the index. I have nothing to hide.

That just seems wasteful and clutterish. If too much of that occurs, the index could be littered with it. Sort of like old PGP keys that never go away.

In 10,000 years, the Go code will be lost, but bored future people will reconstruct it from its hash through shear brute force searching.

More seriously, if the hashes turn out to have serious security flaws, someone may be able to reconstruct the file someday.

> More seriously, if the hashes turn out to have serious security flaws, someone may be able to reconstruct the file someday.

Unlikely. The pidgeon-hole principle applies here, there are many equally likely Go source files that hash to the same thing (regardless of hash function).

The pigeon hole principle will find files that are not syntactically correct Go or of an unrealistic length unless there are really adversarially crafted inputs before the hash.

I filed a bug that this was not spoken about in the announcement.

It would seems like it will cause a lot of drama as this actually rolls out.

https://github.com/golang/go/issues/33980

You have to use the GOPRIVATE env variable to define what not to use the proxy for. https://tip.golang.org/cmd/go/#hdr-Module_configuration_for_...

Thank you for this. It seems they've thought of almost everything we do.

Reply on news.ycombinator.com