https://bugs.winehq.org/show_bug.cgi?id=55304
--- Comment #15 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Hans Leidekker from comment #14)
(In reply to Dmitry Timoshkov from comment #13)
(In reply to Hans Leidekker from comment #12)
It comes from a test that calls QueryContextAttributesA(SECPKG_ATTR_SIZES) under Windows 10 for the Samba server.
Hmm, maybe it's not decrypting in-place? This used to work without querying the trailer size from the context.
It does encrypt/decrypt in place, however as far as I understand it in win32 data and trailer are separate buffers while gss_wrap/gss_unwrap operate on a continuous buffer, and using wrong trailer size creates a hole between data and trailer which breaks gss_wrap/gss_unwrap assumptions.
The _iov variants should be compatible with win32 and I'm pretty sure this worked before. I'd like to figure out why it doesn't work anymore.
As I can see iov variants are used only for DCE style contexts, and that's not the case for the GSSAPI plugin.
Right, previously we'd use the Unix LDAP library which links to SASL which in turn links to GSSAPI. I'll check SASL to see how it uses GSSAPI.
Just in case it could be useful: when working on the attached patchset for the testing purposes and better understanding how native SASL GSSAPI plugin works I created a linux test program that connects to the test server using ldap_sasl_interactive_bind_s() and calls ldap_search_ext_s(). Then I statically linked this test program with libldap and libsasl2, and experimented with the plugin. Sources that were used in the experiments I listed in the first comment.