Force a single private repo for SOC2 environments

[jacek99]

At work, we have to work in a locked down SOC2 environment.
That means that we cannot download ANYTHING off the public Internet when doing builds.

Everything has to be mirrored internally on our network and manually verified prior to pulling in new updates

It would be great if glide could allow specifying a single master private repo and ONLY look in that repo for all the packages and their dependencies.

Otherwise we cannot use Go in SOC2 environments...it's been a blocker for any Go adoption in a more secure environment. All of our customers want SOC2, so without Go integrating cleanly with its security requirement, we have no option but Java (which easily handles it with local Maven repositories with products like Artifactory, etc).

Much appreciated.

[franciscocpg]

hi @jacek99,
repo in glide.yaml does not help?

[jacek99]

Sure, but it is per package. So if I have a project with 50 dependencies, I have to specify that explicitly on every package. And even if that package is in my private repo, I presume you will look for its dependencies in the original location (e.g. github).

Instead we need a global (i.e. default for all packages) repo definition and restrict ALL dependency resolution to only look in that private repo and never anywhere else.

E.g. like in Ruby Bundler, where you can specify the gems repo in the Gemfile, e.g.

source 'https://rubygems.org'

or in Java Gradle, where you can specify explicitly which repositories the build is allowed to search:

repositories {
    maven {
        url'http://arttifactory.mycompany.com/artifactory/repo'
    }
}

[jacek99]

Basically tell it in one central location that you are allowed to look in this git repo (with some base prefix URL I presume) and never look anywhere else.

Without this type of locking down, using Go is a no-go in a SOC2 environment.

[jacek99]

Let's say I mirror the selected Go projects in a Stash instance on our network, I would love to be able to add at the root of the yaml file something like

privateRepo: stash.mycompany.com/projects/go-libs

and then for any library, lets say 'github.com/gin' glide would know to automatically look at

stash.mycompany.com/projects/go-libs/github.com/gin

and similarly for all the dependencies it refers to in its vendor file.

[franciscocpg]

I see @jacek99
Just some thoughts about it:

It would be great if glide could allow specifying a single master private repo and ONLY look in that repo for all the packages and their dependencies
Basically tell it in one central location that you are allowed to look in this git repo

I don't think golang was designed to work with a centralized repository.
You can read more here https://golang.org/doc/articles/go_command.html, topics Configuration versus convention and Go's conventions

Also I am not sure if glide wants to break go get compatibility: #498

Maybe git insteadof may help you.
And I recommend the reading of go help importpath command output.

I am not saying that your idea is good or not, but definitely is not following the golang conventions (which we know is a very opinionated language).

[jacek99]

I understand, but that is unfortunate. Many organizations will be required to work under SOC2 due to requests from customers (especially for customer data security) and in this case Go is totally out, can't even be evaluated as an option.

Very unfortunate.

[sdboyer]

As I mentioned on the mailing list, you're not the first to raise this issue. Some issues with at least some overlap: #372 and #594.

I suspect we may not get to this in glide, in favor of working on it instead in the new tooling. But it's not a forgotten use case - just one that we can't get to right away.

In the meantime, I do agree with the assessment others have made of this statement:

Many organizations will be required to work under SOC2 due to requests from customers (especially for customer data security) and in this case Go is totally out, can't even be evaluated as an option.

I don't think this requirement eliminates Go - only go get, glide, and most (all?) other current dep mgr tooling. It's perfectly possible for you to construct such build environments from pre-verified code yourself; the compiler works exclusively on local disk. I realize that's probably small solace, but it's still an important distinction.