Comment 1:

Very little details. Perhaps, you could investigate more. Maybe run tests in
crypto/x509, with "-v" ?
Thank you.
Alex

Status changed to WaitingForReply.

Comment 2 by raul.san@sent.com:

C:\go-src\src\pkg\crypto\x509>go test -v
=== RUN TestPKCS8
--- PASS: TestPKCS8 (0.05 seconds)
=== RUN TestGoVerify
--- PASS: TestGoVerify (0.02 seconds)
=== RUN TestSystemVerify
exit status 128
FAIL    _/C_/go-src/src/pkg/crypto/x509 0.453s

Comment 3:

Still do not see what is happening here. I take it, TestSystemVerify fails. Does it?
Perhaps, you could put some prints in the test to see how far it gets. Thank you.
Alex

Comment 4 by raul.san@sent.com:

I though that the error would be reproducible to another people. I'm using Windows XP 64
bits like guest in VirtualBox under Ubuntu.

Comment 5:

I can't reproduce it here. Many different systems. Virtual and not. None of those is
VirtualBox.
But don't let it discourage you from bug hunting. Thank you.
Alex

Comment 6 by raul.san@sent.com:

The error is produced after of:
http://golang.org/src/pkg/crypto/x509/verify_test.go#L187
So I, added:
  println("ok")
  chains, err := leaf.Verify(opts)
  fmt.Println("i:", i, "ERR:", err)
and I commented function TestGoVerify since it calls to testVerify() too
and this is the output:
=== RUN TestSystemVerify
ok
exit status 128
* * *
Like you can see, it exits directly ar running that function: leaf.Verify(opts)

Comment 7 by raul.san@sent.com:

The failure is here:
http://golang.org/src/pkg/crypto/x509/verify.go#L157
I added:
    println("FOO")
    if opts.Roots == nil && runtime.GOOS == "windows" {
        return c.systemVerify(&opts)
    }
    println("BAR")
and the output is:
FOO
exit status 128
* * *
I hope it helps, tell me if I can help in some more

Comment 8:

it seems the code abnormally exits without any error messages?
if it is the case,
could you please use gdb to run x509.test can see if you can
get a backtrace and detailed reason about the exit?
Or, you can continue put printlns in systemVerify in 
http://golang.org/src/pkg/crypto/x509/root_windows.go.
NOTE: I can't reproduce this either.

Comment 9 by raul.san@sent.com:

and going back, here you have the line where it fails:
http://golang.org/src/pkg/crypto/x509/root_windows.go#L197
    err = syscall.CertGetCertificateChain(syscall.Handle(0), storeCtx, verifyTime, storeCtx.Store, para, 0, 0, &chainCtx)
* * *
It fails on this syscall.

Comment 10:

what does err say? is it nil? or it just fails to return and immediate exits?

Comment 11 by raul.san@sent.com:

I put a println before and after of that line, and it is only showed the first one. So
it just fails at running and exit, it does not get the error.

Comment 12:

What happens if you change one line:
# hg diff root_windows.go
diff -r d04dcbbb5f91 src/pkg/crypto/x509/root_windows.go
--- a/src/pkg/crypto/x509/root_windows.go       Sat Sep 29 12:43:05 2012 +0900
+++ b/src/pkg/crypto/x509/root_windows.go       Sun Sep 30 00:26:11 2012 +1000
@@ -154,7 +154,7 @@
        // If there's a DNSName set in opts, assume we're verifying
        // a certificate from a TLS server.
-       if hasDNSName {
+       if false {
                oids := []*byte{
                        &syscall.OID_PKIX_KP_SERVER_AUTH[0],
                        // Both IE and Chrome allow certificates with
#
I am running this version:
# hg id 
d04dcbbb5f91+ tip
Thank you.
Alex

Comment 13 by raul.san@sent.com:

Nothing, the same failure.

Comment 14:

I do not know what else to suggest. But I will accept this issue for now.
Alex

Status changed to Accepted.

Comment 16:

Labels changed: added go1.1.

Comment 17:

No one else seems to be running into this or able to reproduce it. I will leave it open
but at low priority.

Labels changed: added priority-someday, removed priority-triage, go1.1.

Comment 18:

raul.san sent me an os image and installation instructions for the system that fails. It
does fails for me too, but not since
changeset:   14859:4e14b1d8a88d
user:        Roger Peppe <rogpeppe@gmail.com>
date:        Mon Nov 12 15:29:17 2012 +0000
summary:     encoding/pem: write Proc-Type header first.
Even still it is not broken now, I would still like to understand what the problem was.
Unfortunately, the failure is difficult to trace, because it disappears if I run
executable under gdb.
If anyone has good suggestions, I am happy to try them.
Alex

Comment 19:

I give up. :-)

Status changed to Unfortunate.

Comment 20 by raul.san@sent.com:

Fixed! It was solved at installing update for Root certificate: KB931125
http://support.microsoft.com/kb/931125