Comment 1:

Labels changed: added repo-main, release-go1.3maybe, os-windows.

Comment 2:

I agree. The cgi executable would be started by IIS, and would be running under "Local
System" (or similar) system account. So it wouldn't have access to any "user profile".
From http://support.microsoft.com/kb/238187:
>>>
For these examples, CRYPT_MACHINE_KEYSET is used because the security context in which
the application is running does not have access to a user profile.
<<<
I made this change:
diff --git a/src/pkg/crypto/rand/rand_windows.go b/src/pkg/crypto/rand/rand_windows.go
--- a/src/pkg/crypto/rand/rand_windows.go
+++ b/src/pkg/crypto/rand/rand_windows.go
@@ -27,7 +27,7 @@
    r.mu.Lock()
    if r.prov == 0 {
        const provType = syscall.PROV_RSA_FULL
-       const flags = syscall.CRYPT_VERIFYCONTEXT | syscall.CRYPT_SILENT
+       const flags = syscall.CRYPT_VERIFYCONTEXT | syscall.CRYPT_SILENT |
syscall.CRYPT_MACHINE_KEYSET
        err := syscall.CryptAcquireContext(&r.prov, nil, nil, provType, flags)
        if err != nil {
            r.mu.Unlock()
and all tests still pass. (gloume, can you please see if it helps your case?)
But I am not convinced it is safe to simply add syscall.CRYPT_MACHINE_KEYSET in general
case. See syscall.CRYPT_MACHINE_KEYSET description in
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379886(v=vs.85).aspx for
details. Perhaps I'm mistaken.
Alternatively, we can try and include syscall.CRYPT_MACHINE_KEYSET selectively. We can
detect, if we're running as service like so
http://godoc.org/code.google.com/p/winsvc/svc#IsAnInteractiveSession, and include
syscall.CRYPT_MACHINE_KEYSET only then. But it complicates things for everyone.
Looking for suggestions.
Alex

Comment 3:

Unfortunately, it appears that this simple flag does not fix the issue for
me.
Assuming there is some other combination of magic flags that will fix the
issue, could we create an init function in rand_windows.go (or a shared
platform-specific location) that is similar to IsAnInteractiveSession and
sets a boolean for the whole process? That would make for an easy check in
Read(), but it assumes that a process can't transition from interactive to
non-interactive.
Josh

Comment 4:

> ... Unfortunately, it appears that this simple flag does not fix the issue for me.
Then I don't know what the problem is. Perhaps it wants different flag. Try reading
windows refs and use different flags. I don't have time to play with this now. Maybe
later. Sorry.
Alex

Comment 5:

Labels changed: added release-none, suggested, removed release-go1.3maybe.

Status changed to Accepted.

I tried this but can't reproduce.