https://bugs.winehq.org/show_bug.cgi?id=55304
--- Comment #11 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Dmitry Timoshkov from comment #10)
I don't understand why the trailer size depends on the server since we have always depended on a constant trailer size. Is that because of a difference between Samba and AD?
I've tested with Microsoft and Samba servers and both of them use 60 for actual encryped data, and decrypting with 64 abviously doesn't work. In the same time QueryContextAttributesA(SECPKG_ATTR_SIZES) returns 64 for the connection.
I can find references for Windows changing from 12000 max token size to 48000 but not 48256. Where does it come from?
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.
Also using wrong trailer size leads to incorrect total buffer length passed to gss_unwrap.