x509 failed to load system roots and no roots provided for Darwin builds with Go 1.1

[owenthereal]

I am getting x509 failed to load system roots and no roots provided for Darwin builds. After some googling, I got to know I need to disable cgo (https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/z9Q1wTZNR7k). But looks like cgo is already disabled when building the toolchain (the Go version is 1.1). Here's the log: https://drone.io/github.com/jingweno/gh/184

[owenthereal]

It's related to code here: https://github.com/laher/goxc/blob/master/executils/exec.go#L117-L130. Will enabling cgo with CGO_ENABLED=1 fix it?

[laher]

Hi, I can see some log messages suggesting that 'go build' didn't pick up some ENV variables. The other bug currently open seems to relate to an ENV vars issue aswell.

So, I'm wondering if the current env is appended to our specified vars instead of prepended, then maybe that'll make a difference. It's just a thought, so I've added some code to alter the way the env is handled.

Anyway please try as follows (after go get -u github.com/laher/goxc ):

goxc -prependcurrentenv=append

This will make the CGO_ENABLED=0 variable one of the first variables in the list, so maybe it'll take more precedence than before.

The verbose option (which you already have set) will also spit out the full ENV. That should show us if it's particularly big or if there's something unusual in there.

Anyway, it's good to see someone using drone.io. I tried it back in December and haven't got round to going back to it.

Let me know how you get on. Cheers

[laher]

OK I've got feedback from the other 'issue', and this seems to fix it at least for the other situation.

So I've removed that option again and changed the behaviour to replace any environment variables instead of prepending or appending.
Please ignore the info about 'prependcurrentenv'.

So now, if you were to run CGO_ENABLED=fish goxc, the CGO_ENABLED=fish will be ignored during 'go build'

You'll see an extra log entry during each 'go build' task, e.g.

[goxc:xc] 2013/06/14 08:45:03 Overriding ENV variable (CGO_ENABLED=0 replaces CGO_ENABLED=fish)
[goxc:xc] 2013/06/14 08:45:03 specified env vars for 'go': [GOOS=freebsd CGO_ENABLED=0 GOARCH=386]
[goxc:xc] 2013/06/14 08:45:03 invoking 'go build -ldflags "-X main.VERSION 0.7.4" -o ../goxc-pages/dl/0.7.4/freebsd_386/goxc .' from '.'

Please let me know if this helps
Cheers

[owenthereal]

Do you suggest me to explicitly put CGO_ENABLED=0 as the env variable?

[owenthereal]

Just got some clarifications from go-nut. It's due to cross-compile won't work for loading x509 cert...

[laher]

Hi, I was attempting to fix the first error message during build, thinking that it might fix your runtime issue. I guess it wasn't the problem in this case.
I didn't realise that there was such a limitation of the cross-compiler. That's bad news. I hadn't tried using x509 with cross-compiled binaries before.

I'd like to add a check for goxc to warn about use of SSL, but it's not always possible to know at compile time. I guess I'll just add a note to the readme instead.

[laher]

Suggestion for your immediate problem: distribute the github.com certificate chain inside 'gh', and then load the chain into your tls.Config.

See this gist as proof of concept.
I loaded up the github certificate chain (root & intermediate) into an empty CertPool, then it (i) successfully connects to github, and (ii) fails to connect facebook:
https://gist.github.com/laher/5795578

In this case I added the certificate to a new 'CertPool', but you could add it to the existing CertPool, so it doesn't lose the existing CAs.
You could even do this in a file with build flags +build darwin,!cgo, so that it only affects the cross-compiled binary.
Provided github don't change certificate providers, you wouldn't have to update these bundled CA certs until 2018 :)

Just to backtrack a little: the problem as identified on the golang-nuts thread, is that the cross-compiler can't use 'cgo' during compilation, but 'cgo' is required to access the root certificate store on Darwin. So, this is out of the hands of goxc (it's just a wrapper around the go toolchain).
..
I wouldn't know how to try to access that certificate store, BUT, given that 'gh' only needs to contact *.github.com, do you think that it would be acceptable (legal?) to distribute the certificate along with your binary?

Hope that helps

[owenthereal]

Thanks @laher. Looks like I have other native codes that require building on different platforms. I ended up building the binary on each platform. This issue is not relative to goxc but more in general relative to how cross compile works. Hence closing this issue.

[ftaher]

I had a similar issue, was solved after copying crt file from any of these linux distro. for golang to read the file, you have to place the file in the exact same directory. crypto/x509 will loop over all the possible certificate files.

// Possible certificate files; stop after finding one.
var certFiles = []string{
"/etc/ssl/certs/ca-certificates.crt", // Debian/Ubuntu/Gentoo etc.
"/etc/pki/tls/certs/ca-bundle.crt", // Fedora/RHEL
"/etc/ssl/ca-bundle.pem", // OpenSUSE
"/etc/ssl/cert.pem", // OpenBSD
"/usr/local/share/certs/ca-root-nss.crt", // FreeBSD/DragonFly
}

func (c _Certificate) systemVerify(opts *VerifyOptions) (chains [][]_Certificate, err error) {
return nil, nil
}

func initSystemRoots() {
roots := NewCertPool()
for _, file := range certFiles {
data, err := ioutil.ReadFile(file)
if err == nil {
roots.AppendCertsFromPEM(data)
systemRoots = roots
return
}
}

    // All of the files failed to load. systemRoots will be nil which will
    // trigger a specific error at verification time.

}