Dmitry Timoshkov dmitry@baikal.ru wrote:
Hans Leidekker hans@codeweavers.com wrote:
Could you please provide the test sources along with the following log: KRB5_TRACE=/dev/stdout WINEDEBUG=+secur32 wine yourtest.exe
Attached log is from runnning this command with your debug patch applied: KRB5_TRACE=/dev/stdout WINEDEBUG=+secur32,+kerberos ../../../tools/runtest -P wine -T ../../.. -M secur32.dll -p secur32_test.exe.so kerberos
Thanks. From the log:
0009:trace:kerberos:kerberos_SpSealMessage (7c623a20 0x00000000 0x32fc64 0) 0009:trace:kerberos:kerberos_SpSealMessage gss_wrap_iov returned 000d0000 minor status 00000016 0009:trace:kerberos:trace_gss_status_ex GSS-API error: 0x000d0000: "Unspecified GSS failure. Minor code may provide more information" 0009:trace:kerberos:trace_gss_status_ex GSS-API error: 0x00000016: "Invalid argument"
Looks like gss_wrap_iov() depends on GSS_C_DCE_STYLE being provided at the context creation time. That's weird, I can't find an explanation that this flag is required for this API.
https://web.mit.edu/kerberos/krb5-1.12/doc/appdev/gssapi.html "If the context was established using the GSS_C_DCE_STYLE flag (described in RFC 4757), wrap tokens compatible with Microsoft DCE RPC can be constructed. In this case, the IOV list must include a SIGN_ONLY buffer, a DATA buffer, a second SIGN_ONLY buffer, and a HEADER buffer in that order (the order of the buffer contents remains arbitrary). The application must pad the DATA buffer to a multiple of 16 bytes as no padding or trailer buffer is used."
So the implementation of kerberos_SpSealMessage() should be fixed. Since this is your code would you mind have a look at it?