5 ms·

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 publ

by w8rbt 7y ago

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?

donatj 7y ago
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_non_public_modules https://tip.golang.org/cmd/go/#hdr-Module_configuration_for_...
- w8rbt 7y ago
  Thank you for this. It seems they've thought of almost everything we do.
ainar-g 7y ago
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_non_public_modules https://tip.golang.org/cmd/go/#hdr-Module_configuration_for_...
- w8rbt 7y ago
  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.
  - earthboundkid 7y ago
    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.
    - cyphar 7y ago
      > 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).
      - earthboundkid 7y ago
        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.
FiloSottile 7y ago
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_non_public_modules 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.
- etc_passwd 7y ago
  ...but references to them are stored by google in logs and used per the privacy policy at https://proxy.golang.org/privacy https://proxy.golang.org/privacy
hammerandtongs 7y ago
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 https://github.com/golang/go/issues/33980

by w8rbt 7y ago

donatj 7y ago

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_non_public_modules https://tip.golang.org/cmd/go/#hdr-Module_configuration_for_...

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

ainar-g 7y ago

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_non_public_modules https://tip.golang.org/cmd/go/#hdr-Module_configuration_for_...

w8rbt 7y ago
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.
- earthboundkid 7y ago
  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.
  - cyphar 7y ago
    > 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).
    - earthboundkid 7y ago
      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.

FiloSottile 7y ago

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_non_public_modules 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.

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

hammerandtongs 7y ago

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 https://github.com/golang/go/issues/33980