Go SSL segfault on nix darwin

[robx]

Issue description

This is from the comments #18223 (which might be closed because go1.6 does build on darwin).

Go programs that use SSL segfault when neither SSL_CERT_FILE nor NIX_SSL_CERT_FILE environment variables are set.

I'm not sure about the impact of this and the whole story around {NIX_,}SSL_CERT_FILE, but it seems that the program shouldn't segfault, but error out at worst.

Steps to reproduce

Put the expression below (due to @zimbatm) in default.nix, run nix-build.

{ pkgs ? import <nixpkgs> {} }:
let
  inherit (pkgs) stdenv buildGoPackage;
in
  buildGoPackage {
    name = "foo";
    goPackagePath = "github.com/foo/bar";
    src = stdenv.mkDerivation {
      name = "foo-src";
      phases = [ "installPhase" ];
      installPhase = ''
        mkdir $out
        cat <<MAIN > $out/main.go
package main

import (
        "fmt"
        "net/http"
)

func main() {
        resp, err := http.Get("https://google.com/")
        fmt.Println("all good", resp, err)
}
MAIN
      '';
    };
  }

(or see https://gist.githubusercontent.com/zimbatm/8a67bd43242eaaed75924bd25e6fb5c6/raw/1537770e6db2d908fd524c4ff66caf2224e73139/default.nix)

Then run:

$ unset NIX_SSL_CERTFILE
$ unset SSL_CERTFILE
$ ./result-bin/bin/bar
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x144c05b]
...

Technical details

• System: darwin 16.6.0
• Nix version: 1.11.11
• Nixpkgs version: 17.09pre110532.50831d543d
• Sandboxing enabled: no

[copumpkin]

This will probably be addressed by #24693, but I haven't had time to address that. Any volunteers to try implementing?

[LnL7]

The reason it doesn't segfault when NIX_SSL_CERT_FILE is set it because of a patch that tries to avoid the code that interacts with Security.framework.
If you look at the go binary you can see that it's liked to the pure CF, that's probably what's causing the issue.

$ otool -L result/bin/.go-wrapped
result/bin/.go-wrapped:
        /nix/store/vc9p7pwswiwqc1shxwj8w638wh3qfr5c-CF-osx-10.10.5/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 0.0.0, current version 0.0.0)
        /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 0.0.0, current version 0.0.0)
        /nix/store/p3aw3a3qx1nxpzz5irk7lbwl3zw9syw3-Libsystem-osx-10.11.6/lib/libSystem.B.dylib (compatibility version 0.0.0, current version 0.0.0)
        /nix/store/p3aw3a3qx1nxpzz5irk7lbwl3zw9syw3-Libsystem-osx-10.11.6/lib/libSystem.B.dylib (compatibility version 0.0.0, current version 0.0.0)
        /nix/store/p3aw3a3qx1nxpzz5irk7lbwl3zw9syw3-Libsystem-osx-10.11.6/lib/libSystem.B.dylib (compatibility version 0.0.0, current version 0.0.0)

We could fix the binary by patching it there, similar to what we do for dylibs. But that doesn't help projects that use x509 so #24693 is needed for a general solution. I'll see if I can find some time to look at it.

[LnL7]

Fixed by #27598