http://bugs.winehq.org/show_bug.cgi?id=21870
--- Comment #10 from Jim Cameron jim_24601@btinternet.com 2010-05-01 19:58:02 --- Created an attachment (id=27657) --> (http://bugs.winehq.org/attachment.cgi?id=27657) Changes to DecryptMessage() for the Steam client
The patch to bug 3254 returns a buffer of type SECBUFFER_EMPTY if there is additional data it can't handle yet, but does not set its pvBuffer field up. The MSDN article linked from the post states that "The pvBuffer field of the extra buffer does not contain a copy of the excess data." but it does not say what it in fact contains. Steam tries to copy data out of it, so it must refer to the excess data; if it isn't a copy, it must therefore point to the excess within the input buffer.
It also turns out that Steam is expecting a SECBUFFER_DATA buffer to be set up in one of the output buffers on return. Since DecryptMessage is stated to decrypt the data in place, this must again be a pointer to the input buffer, now holding the decrypted data, and its length set appropriately.
It also turns out that in response to a SEC_E_INCOMPLETE_MESSAGE result, the Windows application will re-present all the data, however our gnutls back-end has already swallowed the first part of the message and does not want it again. We must keep track of this.
The attached patch does these things. The steam client successfully accesses the secure server and brings back a form for me to fill in my details. Unfortunately the drop-down lists don't work, so I can't actually fill it in correctly. That's likely another problem, though.