Self-signed certificates

[rosspeoples]

As mentioned in #286, we use GitHub Enterprise internally and all the certs are generated by an internal CA that is trusted at the user level, but not at the system level, so we currently have to use some git replacement rules to workaround the issue, since most command-line utilities don't recognize the internal CA.

There should be a way to specify an internal CA for SSL/TLS verification, or at least provide a way to ignore it.

[ascandella]

I'm also interested in this. We use code.$COMPANY.internal which for obvious reasons we can't get a "proper" SSL cert but do have configured to resolve and work via git/ssh. Obviously none of our stuff is go-gettable (which I don't really care about -- we build packages for stuff that's important enough to distribute) but does bother people.

The thing that really is a bummer is that internal libraries need to have ".git" in their import path to work properly with glide.

[sdboyer]

definitely makes sense. unfortunately, i know essentially nothing about making this work. someone else will have to drive it (though i can guide, ofc).

the general comments i can make are:

1. we shell out to the underlying vcs for everything we do, so whatever solution we come up with we'll likely have to shoehorn differently for each of the vcs tools.
2. the spot where it may be easy(-er) is for go-get metadata requests, as those are actual in-process HTTP requests.
3. i'd be open to introducing a more general system/user/local config file pattern for parameters that we specifically want to inject into the SourceManager. this seems like it might be a good candidate for that.

side note - I want to find some kind of bucket into which we can put all these internal-org conversations. Not because I want to ignore them, but because I feel like I can't do anything but ignore them until we have a framework for organizing and addressing them 😦

[themanifold]

For anyone stuck on this, please see: #1898 (comment)