[Bug 19781] New: Visual C++ 2005 Express: -Zi option doesn't work; breaks Firefox build's configure script
http://bugs.winehq.org/show_bug.cgi?id=19781 Summary: Visual C++ 2005 Express: -Zi option doesn't work; breaks Firefox build's configure script Product: Wine Version: 1.1.27 Platform: PC OS/Version: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com Firefox's configure script quite reasonably tries cl -Zi to see if -Zi works. Under Wine, sadly, it doesn't. To reproduce, you have to get past bug 19779 by copying C:/Program Files/Microsoft Visual Studio 8/Common7/IDE/mspdb* to C:/windows/system32. Then try cd ~/.wine/drive_c/Program Files/Microsoft Visual Studio 8/Common7/Tools cp ~/hello.c . wine cmd vsvars32.bat cl -Zi hello.c This causes mspdbsrv.exe -start -spawn to run and persist, but it seems that cl can't talk to that service properly; repeating the command cl -Zi hello.c yields Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. hello.c fixme:ole:NdrCorrelationInitialize (0x33e48c, 0x33e08c, 1024, 0x0): stub fixme:netapi32:NetWkstaUserGetInfo Level 1 processing is partially implemented fixme:advapi:LsaOpenPolicy ((null),0x33dc98,0x00000001,0x33dcb4) stub fixme:advapi:LsaClose (0xcafe) stub MSPDBSRV: fatal error: Unable to start server: server already exist fixme:ole:NdrCorrelationInitialize (0x33e48c, 0x33e08c, 1024, 0x0): stub fixme:netapi32:NetWkstaUserGetInfo Level 1 processing is partially implemented fixme:advapi:LsaOpenPolicy ((null),0x33dc98,0x00000001,0x33dcb4) stub fixme:advapi:LsaClose (0xcafe) stub hello.c : fatal error C1902: Program database manager mismatch; please check your installation -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #1 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-09-21 04:39:05 --- Something is going wrong with ntlm_auth helper, so far I'm not sure what. Perhaps Kai could help here. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #2 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-09-23 05:14:03 --- In order to simplify debugging I've added all environment varibales from vsvars32.bat to System\CurrentControlSet\Control\Session Manager\Environment, and run 'mspdbsrv.exe -start -spawn ' and 'cl -Zi hello.c' from separate terminals. Dan, could you please generate and attach the +relay,+seh,+tid,+secur32,+ntlm log to see if that shows the same failure (with ntlm_auth) I have? Just in case that should be WINEDEBUG=+relay,+seh,+tid,+secur32,+ntlm wine cl -Zi hello.c &>~/cl.log -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 Hans Leidekker <hans(a)meelstraat.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hans(a)meelstraat.net --- Comment #3 from Hans Leidekker <hans(a)meelstraat.net> 2009-09-23 07:48:20 --- I can reproduce this here. Looks like ntlm_auth fails because it's not supplied with a password and it can't retrieve any cached credentials. I wonder if such a call sequence would succeed on Windows because the user has already logged on to the OS? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #4 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-09-23 09:18:07 --- (In reply to comment #3)
I can reproduce this here. Looks like ntlm_auth fails because it's not supplied with a password and it can't retrieve any cached credentials.
Yep, exactly the same symptoms here.
I wonder if such a call sequence would succeed on Windows because the user has already logged on to the OS?
I don't see anything wrong with the call sequence, the app does AcquireCredentialsHandleW() followed by InitializeSecurityContextW(). That's a normal sequence to start with. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |rpc --- Comment #5 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-09-29 05:45:32 --- This seems to be an rpcrt4.dll issue. It's RPCRT4_ClientAuthorize() who calls InitializeSecurityContextW() which in turn fails. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #6 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-09-30 07:54:41 --- The app does: GetUserNameEx(NameSamCompatible, user_name, &len); RpcBindingSetAuthInfoExW(&binding, user_name, RPC_C_AUTHN_LEVEL_PKT_PRIVACY, RPC_C_AUTHN_WINNT, NULL, RPC_C_AUTHN_DEFAULT, &qos); then an RPC call happens which leads to InitializeSecurityContextW() which fails. The problem seems to be caused by the fact that the app doesn't pass any authentication info to RpcBindingSetAuthInfoExW, although MSDN states that "When using the RPC_C_AUTHN_WINNT authentication service AuthIdentity should be a pointer to a SEC_WINNT_AUTH_IDENTITY structure" and "Specify a null value to use the security login context for the current address space." The app passes NULL as AuthIdentity handle, and RpcBindingSetAuthInfoExW tries to get an existing authentication credentials, and it appears that secur32/ntlm_auth can't cope with that. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mathieu.malaterre(a)gmail.com --- Comment #7 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-10-05 00:24:24 --- *** Bug 20241 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #8 from Hans Leidekker <hans(a)meelstraat.net> 2009-10-06 03:34:19 --- I've submitted a test showing that InitializeSecurityContext returns SEC_I_CONTINUE_NEEDED after supplying null authentication data to AcquireCredentialsHandle. The problem is that on Wine there's currently no concept of a "security login context for the current address space", as msdn calls it. This is what will be used when you pass null authentication data to AcquireCredentialsHandle. You can work around this bug by caching credentials, e.g. with code like this: CREDENTIALA cred; static WCHAR pwd[] = {'p','w','d'}; static char user[] = {'h','o','s','t','\\','u','s','e','r',0}; memset(&cred, 0, sizeof(cred)); cred.Type = CRED_TYPE_DOMAIN_PASSWORD; cred.TargetName = user; cred.CredentialBlobSize = sizeof(pwd); cred.CredentialBlob = (LPBYTE)pwd; cred.Persist = CRED_PERSIST_SESSION; cred.UserName = user; CredWriteA(&cred, 0); Substituting static data appropriately, of course. Now InitializeSecurityContext will return SEC_I_CONTINUE_NEEDED and we run into another crash: 001a:Ret secur32.EncryptMessage() retval=80090321 ret=7eb3f895 001a:err:rpc:RPCRT4_SecurePacket EncryptMessage failed with 0x80090321 001a:Call ntdll.RtlFreeHeap(00110000,00000000,001699b8) ret=7eb408ce 001a:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7eb408ce 001a:Call ntdll.RtlFreeHeap(00110000,00000000,00169b10) ret=7eb3f356 001a:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7eb3f356 001a:Call KERNEL32.RaiseException(00000721,00000000,00000000,00000000) ret=7eb4d405 80090321 == SEC_E_BUFFER_TOO_SMALL. Is rpcrt4 calling EncryptMessage too early, i.e. before completing the ntlm handshake? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 Alan Jones <skyphyr(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |skyphyr(a)gmail.com --- Comment #9 from Alan Jones <skyphyr(a)gmail.com> 2009-10-08 23:09:37 --- As would be expected this also occurs with VS2008. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #10 from Kai Blin <kai.blin(a)gmail.com> 2009-10-14 01:13:15 --- I'll try to get this setup on my system, but while I'm looking into that, could anybody who already has the setup get me a +ntlm,+secur32 trace? One other thing.. ntlm_auth doesn't do authentication standalone. Is vc expecting to have a domain environment around? If it's trying to do NTLM auth locally, we're in trouble, as we can't do that. We could try and fake something there, but I haven't seen any calls to AcceptSecurityContext, so I'm not sure if that's being called at all. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #11 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-10-14 02:41:03 --- (In reply to comment #10)
I'll try to get this setup on my system, but while I'm looking into that, could anybody who already has the setup get me a +ntlm,+secur32 trace?
The test Hans added is supposed to replicate the problem. Does the test pass for you? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #12 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-10-14 02:48:35 --- Here is the test: http://source.winehq.org/git/wine.git/?a=commitdiff;h=8bb68933ea37766c3fd4ed... And yes, the app tries to get an authentication with the local service via rpc. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #13 from Kai Blin <kai.blin(a)gmail.com> 2009-10-14 06:15:52 --- (In reply to comment #11)
(In reply to comment #10)
I'll try to get this setup on my system, but while I'm looking into that, could anybody who already has the setup get me a +ntlm,+secur32 trace?
The test Hans added is supposed to replicate the problem. Does the test pass for you?
Nope. Let me check if this works when I'm authenticated via winbind and I can get a winbind credential from the cache. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 Kai Blin <kai.blin(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kai.blin(a)gmail.com --- Comment #14 from Kai Blin <kai.blin(a)gmail.com> 2009-10-14 06:36:00 --- (In reply to comment #11)
The test Hans added is supposed to replicate the problem. Does the test pass for you?
Right, I missed that. Sorry. Nope, as expected it doesn't pass for me either. This is Rob's cached credentials code, I never got the Wine-side credential cache to work myself. :) I know of one user who uses the winbind cached credentials, but the wine cred cache seems to be pretty un-tested (and broken, no big surprise). (In reply to comment #12)
And yes, the app tries to get an authentication with the local service via rpc.
I think we could cheat our way through this here. I haven't looked into this stuff for a while, but all we need to come up with for the local case is a username/password combination ntlm_auth will accept for the "server" side. You can easily bypass the usual check ntlm_auth does for the server side by running ntlm_auth with --username=user --password=pass --domain=dom So assuming ntlm_GetCachedCredential() returned user WINE\bob and password secret if there's no real cached credentials... we'll handsomely break winbind-based cached credentials if we need to authenticate against a remote server. I'll have to give this some more thought. Sorry I can't provide you with a ready solution here. A long-term fix would be to get Samba winbindd to also be able to authenticate local users (like the local SAM on a windows machine) and store that user's creds in the winbind cache at login time, just like it does for domain logins. Then Wine could always use the winbind credentials cache. Unfortunately, winbindd can't do that quite yet, probably a couple of man-weeks worth of work on Wine and Samba if you know where to look. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #15 from Kai Blin <kai.blin(a)gmail.com> 2009-10-14 06:36:31 --- (In reply to comment #13)
(In reply to comment #11)
(In reply to comment #10)
I'll try to get this setup on my system, but while I'm looking into that, could anybody who already has the setup get me a +ntlm,+secur32 trace?
The test Hans added is supposed to replicate the problem. Does the test pass for you?
Nope. Let me check if this works when I'm authenticated via winbind and I can get a winbind credential from the cache.
Scratch that, didn't think about that one enough. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #16 from Kai Blin <kai.blin(a)gmail.com> 2009-10-14 12:47:56 --- Created an attachment (id=24129) --> (http://bugs.winehq.org/attachment.cgi?id=24129) Use empty passwird if cached credentials fail Work-around for the failing cached credentials. This sends an empty password to make ntlm_auth happy. With this workaround, we should be able to get to the point where the server side of the RPC fails. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #17 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-10-15 01:09:44 --- (In reply to comment #16)
Work-around for the failing cached credentials. This sends an empty password to make ntlm_auth happy. With this workaround, we should be able to get to the point where the server side of the RPC fails.
Yes, this patch helps. Now the compiler proceeds to the same point as in the Comment #8 for Hans. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #18 from Kai Blin <kai.blin(a)gmail.com> 2009-10-15 01:36:57 --- Can I get a +ntlm trace of that, please? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #19 from Hans Leidekker <hans(a)meelstraat.net> 2009-10-15 03:02:35 --- Created an attachment (id=24143) --> (http://bugs.winehq.org/attachment.cgi?id=24143) +ntlm,+secur32,+rpc trace with patch applied Here's a +ntlm,+secur32,+rpc log. It's not exactly the same failure as with my workaround, EncryptMessage fails here with SEC_E_BUFFER_TOO_SMALL. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #20 from Dan Kegel <dank(a)kegel.com> 2009-10-21 23:22:43 --- I'm jonesin' for this; being able to builds the memcheck test suite under wine with /Zi, and then run it under valgrind+wine would be quite the hat trick. What's the current status? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #21 from Kai Blin <kai.blin(a)gmail.com> 2009-10-22 00:52:04 --- I've got this problem reproduced. The issue seems to be that the RPC code never finishes the NTLM handshake. I've failed to find the correct place to send the initial request to the server, the code seems to assume InitializeSecurityContext takes care of that. While trying to wrap my head around the RPC code, university caught up with me again. I know that I demoed Wine doing NTLM crypto with Outlook in 2006. Did the RPC code significantly change since then? I don't understand how this code would have done the right thing in 2006. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #22 from Hans Leidekker <hans(a)meelstraat.net> 2009-10-22 02:17:49 --- Perhaps you demoed outlook in rpc over https mode? In which case ntlm authentication works fine. I agree that secure rpc's likely have not worked before. At least I can't find the code to build all of the corresponding packets. I found this old perl implementation, perhaps it's useful: http://cpansearch.perl.org/src/UMVUE/DCE-RPC-0.11/lib/DCE/RPC.pm -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #23 from Dan Kegel <dank(a)kegel.com> 2009-10-26 19:47:08 --- Hi Kai, thanks for looking at this. Hope university releases its grip enough to let you wrap your head around it soon! What's the prognosis? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #24 from Kai Blin <kai.blin(a)gmail.com> 2009-10-29 03:21:41 --- (In reply to comment #23)
thanks for looking at this. Hope university releases its grip enough to let you wrap your head around it soon! What's the prognosis?
Well, _if_ I could find my way around the horrible mess that is our RPC code, I might be able to do something. I keep wasting the few hours I have per week at poking around the rpc code. Basically, RPCRT4_ClientAuthorize needs to send the buffer returned from InitializeSecurityContext to the server, then receive the reply from the server and loop on doing that until the result from InitializeSecurityContext isn't SEC_I_CONTINUE anymore. However, so far I haven't managed to find out how to do the "send to server" and "receive from server" parts are supposed to work. I'm stuck at that point. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #25 from Hans Leidekker <hans(a)meelstraat.net> 2009-11-04 02:44:46 --- Created an attachment (id=24545) --> (http://bugs.winehq.org/attachment.cgi?id=24545) rpcrt4: Add secure rpc test. This patch adds a test that reproduces the crash seen in this bug. It applies on top of this patch: http://www.winehq.org/pipermail/wine-patches/2009-November/080899.html My plan was to run the same test over ncacn_ip_tcp on windows and spy on it with wireshark, but alas, I get an unknown exception 0x0000063d when I do that. Same thing with ncacn_np, only ncalrpc seems to allow secure mode. A possible explanation is that I'm supplying default credentials, which are only valid on the machine itself. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #26 from Hans Leidekker <hans(a)meelstraat.net> 2009-11-04 05:04:04 --- I was wrong, it appears that authentication services need to be registered by the rpc server and ncalrpc simply has RPC_C_AUTHN_WINNT registered by default. So, after a call to RpcServerRegisterAuthInfo, my test appears to do secure rpcs over ncacn_ip_tcp. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #27 from Hans Leidekker <hans(a)meelstraat.net> 2009-11-05 07:44:57 --- It's not as bad as I thought, we do support secure rpcs when explicit credentials are supplied in the call to RpcBindingSetAuthInfoEx. This means we're back to the problem of handling default credentials. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #28 from Kai Blin <kai.blin(a)gmail.com> 2009-11-07 04:59:42 --- Actually the problem is that the rpc server side in Wine does not handle authentication whatsoever. It never calls out to SSPI and never attaches a challenge packet to the BIND_ACK reply, so the rpc client code never finishes the handshake. So technically this is an rpc bug. :) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 Rob Shearman <robertshearman(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |robertshearman(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #29 from Rob Shearman <robertshearman(a)gmail.com> 2009-11-07 07:23:06 --- While the app here may benefit from work to add support for authentication on the server side, I suspect that authentication over ncalrpc is special cased to be a no-op in the native DLL. This is supported by Hans' findings that RpcServerRegisterAuthInfo does not need to be called on the server side for the client to be able to succeed whilst specifying NTLM authentication to be applied. More tests need to be done to see whether the identity passed into RpcBindingSetAuthInfo is seen on the server side (RpcBindingInqAuthClient) for ncalrpc & ncacn_ip_tcp. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 Vincent Cappe <vcappe(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vcappe(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 Hans Leidekker <hans(a)meelstraat.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #24545|0 |1 is obsolete| | --- Comment #30 from Hans Leidekker <hans(a)meelstraat.net> 2009-11-17 04:08:59 --- Created an attachment (id=24799) --> (http://bugs.winehq.org/attachment.cgi?id=24799) rpcrt4: Add secure rpc tests.
applied. More tests need to be done to see whether the identity passed into RpcBindingSetAuthInfo is seen on the server side (RpcBindingInqAuthClient) for ncalrpc & ncacn_ip_tcp.
These updated tests succeed here on Windows and crash in the same way cl.exe does on Wine. RpcBindingInqAuthClient does not return a handle to the client identity in the Privs parameter in case of ncalrpc, if that's what you mean. Instead it returns the principal as a Unicode string, as documented on MSDN. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #31 from Rob Shearman <robertshearman(a)gmail.com> 2009-11-29 04:52:50 --- Created an attachment (id=25000) --> (http://bugs.winehq.org/attachment.cgi?id=25000) Patch series add support for RPC server authentication With this patch series applied: - ncacn_ip_tcp attempts to authenticate using SSPI, but fails for me because ntlm_auth can't connect to winbindd (and crashes in DecryptMessage due to a secur32 bug). - ncalrpc doesn't use SSPI for authentication, instead relying on the security built into the LRPC transport. RpcBindingInqAuthClientA/W still need to be fixed to report the connection as authenticated when using ncalrpc but I'm hoping this is enough to allow the application to work for the moment. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #32 from Dan Kegel <dank(a)kegel.com> 2009-11-29 18:53:11 --- Close, but not quite there yet. Doing rm -rf ~/.wine sh winetricks vc2005trial cd ~/.wine/drive_c/Program Files/Microsoft Visual Studio 8/Common7/Tools cp ~/hello.c . wine cmd vsvars32.bat cl -Zi hello.c yields fixme:ole:NdrCorrelationInitialize (0x33e330, 0x33df30, 1024, 0x0): stub fixme:ole:NdrCorrelationInitialize (0x33e330, 0x33df30, 1024, 0x0): stub fixme:rpc:NdrStubCall2 new correlation description not implemented fixme:rpc:calc_arg_size Unhandled type 30 err:rpc:I_RpcReceive we got fault packet with status 0x3e6 fixme:ole:NdrCorrelationInitialize (0x33e330, 0x33df30, 1024, 0x0): stub fixme:rpc:NdrStubCall2 new correlation description not implemented fixme:rpc:calc_arg_size Unhandled type 30 fixme:ole:NdrCorrelationFree (0x33e330): stub hello.c : fatal error C1902: Program database manager mismatch; please check your installation which seems a less dire set of errors than in the original post, but still the app didn't work. (I'm pretty sure the same problem affects both vc2005 trial and vc2005 express.) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #33 from Rob Shearman <robertshearman(a)gmail.com> 2009-12-12 13:16:48 --- Created an attachment (id=25184) --> (http://bugs.winehq.org/attachment.cgi?id=25184) Patch series to allow MS PDB server to work Patch series does: 1. Adds support for context handles in stubless server code. This fixes the following messages: fixme:rpc:calc_arg_size Unhandled type 30 err:rpc:I_RpcReceive we got fault packet with status 0x3e6 2. Add support for [out]-only non-conformant strings. This fixes the following message after the above is fixed: fixme:rpc:calc_arg_size Unhandled type 25 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 Ian McLean <ian(a)perceptivepixel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ian(a)perceptivepixel.com --- Comment #34 from Ian McLean <ian(a)perceptivepixel.com> 2009-12-12 17:00:41 --- I've confirmed that Rob's two latest patches enable PDB generation with: MSPDB71.DLL version 7.10.6030 MSPDB80.DLL version 8.0.50727.762 MSPDB80.DLL version 9.0.30729.1 Built with: CL.EXE version 13.10.6030 CL.EXE version 14.00.50727.762 CL.EXE version 15.00.30729.01 AKA: Microsoft Visual Studio .NET 2003 Microsoft Visual Studio 2005 Microsoft Visual Studio 2008 Non-trivial test; over 500MB of PDBs; many applications and DLLs. Thank you! This closes our cross-compile loop for development builds. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #35 from Dan Kegel <dank(a)kegel.com> 2009-12-12 17:28:17 --- w00t! Looking forward to seeing these on wine-patches... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #36 from Dan Kegel <dank(a)kegel.com> 2009-12-16 02:24:01 --- I see some patches are committed. Is this fixed in git, then? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 Rob Shearman <robertshearman(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #37 from Rob Shearman <robertshearman(a)gmail.com> 2009-12-27 07:35:32 --- All of the patches I attached are now committed so marking this as fixed. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #38 from Dan Kegel <dank(a)kegel.com> 2010-01-04 16:25:47 --- Doesn't seem fixed here today. I did 'winetricks msvc2005trial', then wine cmd vsvars32.bat cl -Zi hello.c or equivalently cd ~/.wine/drive_c/Program Files/Microsoft Visual Studio 8/Common7/IDE wine cl -Zi hello.c but it failed with fixme:rpc:RpcBindingSetAuthInfoExW unsupported AuthnSvc 10 hello.c : fatal error C1902: Program database manager mismatch; please check your installation :-( This was with this morning's git. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #39 from Dan Kegel <dank(a)kegel.com> 2010-01-04 16:36:50 --- For completeness, here's the +rpc log: trace:rpc:RpcStringBindingComposeW ((null),L"ncalrpc",(null),L"mspdb_8.00.50727.42_rtl_32_0000000000000000",(null),0x32e628) trace:rpc:RpcBindingFromStringBindingW (L"ncalrpc:[mspdb_8.00.50727.42_rtl_32_0000000000000000]",0x103296bc) trace:rpc:RpcStringBindingParseW (L"ncalrpc:[mspdb_8.00.50727.42_rtl_32_0000000000000000]",0x32e5dc,0x32e5d8,0x32e5d4,0x32e5d0,0x32e5cc) trace:rpc:RPCRT4_CreateBindingW binding: 0x150648 trace:rpc:RPCRT4_SetBindingObject (*RpcBinding == ^0x150648, UUID == {00000000-0000-0000-0000-000000000000}) trace:rpc:RPCRT4_CompleteBindingW (RpcBinding == ^0x150648, NetworkAddr == L"", EndPoint == L"mspdb_8.00.50727.42_rtl_32_0000000000000000", NetworkOptions == (null)) trace:rpc:RPCRT4_GetAssociation new assoc 0x150c78 trace:rpc:RpcBindingSetAuthInfoExW 0x150648 L"ubuntu\\dank" 6 10 (nil) 4294967295 0x32d5e8 trace:rpc:RpcBindingSetAuthInfoExW SecurityQos { Version=1, Capabilities=0x1, IdentityTracking=0, ImpersonationLevel=3} fixme:rpc:RpcBindingSetAuthInfoExW unsupported AuthnSvc 10 hello.c : fatal error C1902: Program database manager mismatch; please check your installation -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #40 from Dan Kegel <dank(a)kegel.com> 2010-01-04 16:48:45 --- Happens with both Visual C++ 2005 Trial (which takes ages to install) and Visual C++ 2005 Express (which is quite quick to install with winetricks -q vc2005express ). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #41 from Dan Kegel <dank(a)kegel.com> 2010-01-05 05:16:14 --- Rob wrote: --- snip --- AuthnSvc 10 is: #define RPC_C_AUTHN_WINNT 10 Either ntlm_auth is missing (or outdated) on this machine or there has been a regression in secur32. A +ntlm,+secur32 log would probably help diagnose further. --- snip --- I'm not at the machine that had the problem, but I am at another good system, and it's not missing ntlm_auth, so I gave it a whirl, and cl -Zi seems to work here. Maybe we need a winediag log message to catch this case. (In the past, having a missing ntlm_auth module was a no-op, so if there's a warning, people's eyes are trained to ignore it...) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #42 from Kai Blin <kai.blin(a)gmail.com> 2010-01-05 05:29:02 ---
Maybe we need a winediag log message to catch this case. (In the past, having a missing ntlm_auth module was a no-op, so if there's a warning, people's eyes are trained to ignore it...)
There should be a very obvious ERR output if ntlm_auth is missing, along with suggestions on what package to install to fix said problem. If people are ignoring that error and complain about authentication errors, I don't know how to fix _that_. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #43 from Dan Kegel <dank(a)kegel.com> 2010-01-05 05:37:30 --- It's obvious, but it's usually totally safe to ignore, so I do ignore it. Can you generate that warning only in situations where it really matters? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #44 from Kai Blin <kai.blin(a)gmail.com> 2010-01-05 06:37:12 --- (In reply to comment #43)
It's obvious, but it's usually totally safe to ignore, so I do ignore it.
Can you generate that warning only in situations where it really matters?
Currently it's generated when secur32.dll is loaded and fails to initialize the NTLM provider. That seemed like a sane spot for me. It might make sense to add another error in the rpcrt at the point where it expects to use the RPC_C_AUTHN_WINNT AuthSvc and that's not provided. However, that'll only help for apps that get to the secur32 code via the rpcrt4 code. Apps that explicitly use secur32 show different patterns of selecting the provider they want to use, and on secur32.dll load is the only sane spot to complain about ntlm_auth missing. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #45 from Dan Kegel <dank(a)kegel.com> 2010-01-05 10:23:56 --- We could keep the warning you put in, and also add more urgent winediag warnings at the later points of use that popular apps hit, maybe? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 --- Comment #46 from Dan Kegel <dank(a)kegel.com> 2010-01-05 12:18:31 --- 'apt-get install winbind' on the affected machine does indeed solve the problem. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19781 Jeff Zaroyko <jeffz(a)jeffz.name> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #47 from Jeff Zaroyko <jeffz(a)jeffz.name> 2010-01-09 04:46:38 --- Closing bugs fixed in 1.1.36. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=19781 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |d412bcc3aef1ccec410b82fac74 | |e4e55897d9438 CC| |focht(a)gmx.net -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org