August 2023 - Wine-Bugs - list.winehq.org

[Bug 55304] Kerberos authentication stopped to work after PE wldap32 conversion

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=55304 --- Comment #15 from Dmitry Timoshkov <dmitry(a)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. -- 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.

Aug. 5, 2023

[Bug 55304] Kerberos authentication stopped to work after PE wldap32 conversion

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=55304 --- Comment #14 from Hans Leidekker <hans(a)meelstraat.net> --- (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. -- 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.

Aug. 5, 2023

[Bug 55404] Mouse inverted/broken in Eve Online when multiple clients open

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=55404 Kevin Andrews <kjandrews0(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |ArchLinux -- 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.

Aug. 5, 2023

[Bug 55404] Mouse inverted/broken in Eve Online when multiple clients open

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=55404 --- Comment #2 from Kevin Andrews <kjandrews0(a)gmail.com> --- 3 clients open - movement completely inverts 2 clients open - movement judders 1 client open - working OK -- 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.

Aug. 5, 2023

[Bug 55404] Mouse inverted/broken in Eve Online when multiple clients open

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=55404 --- Comment #1 from Kevin Andrews <kjandrews0(a)gmail.com> --- Still an issue on wine-staging 8.13-1 -- 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.

Aug. 5, 2023

[Bug 55404] New: Mouse inverted/broken in Eve Online when multiple clients open

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=55404 Bug ID: 55404 Summary: Mouse inverted/broken in Eve Online when multiple clients open Product: Wine Version: 8.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: kjandrews0(a)gmail.com Distribution: --- Created attachment 74964 --> https://bugs.winehq.org/attachment.cgi?id=74964 Mouse issue shown, close second client, then working correctly. Opening multiple eve online clients, the click and drag to orient the ship in space is now completely inverted on both X and Y axis. Can also be seen in the station when "spinning" the ship. Closing other clients and keeping only one running instantly fixes the issue, starting another client once past character selection starts the issue again. Downgrading from wine-staging-8.11-1-x86_64.pkg.tar.zst to wine-staging-8.9.1-1-x86_64.pkg.tar.zst Resolves the issue Mouse pointer in game does work correctly when clicking areas of the UI, it's just changing the direction of view via click and drag. Same issue in window mode and fixed screen. -- 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.

Aug. 5, 2023

[Bug 55304] Kerberos authentication stopped to work after PE wldap32 conversion

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=55304 --- Comment #13 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (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. -- 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.

Aug. 5, 2023

[Bug 55304] Kerberos authentication stopped to work after PE wldap32 conversion

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=55304 --- Comment #12 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Dmitry Timoshkov from comment #10) > > What about Negotiate? > > Do you have an idea how to test it? Apparently for a proper test it's > necessary to create a connection, and once the connection is set up it's up > to a backend (NTLM/Kerberos) to handle it. Yes, but you'd call QueryContextAttributes() on a Negotiate context handle instead of Kerberos/NTLM. We already have some tests for Negotiate. > (In reply to Hans Leidekker from comment #6) > > (In reply to Dmitry Timoshkov from comment #2) > > > (In reply to Hans Leidekker from comment #1) > > > > SSF is used by ldap_int_sasl_bind() to determine if the SASL security layer > > > > should be used at all. This page documents it as representing the key size > > > > for values > 1: > > > > > > > > https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/sasl.intro-44/ > > > > index.html > > > > > > libldap simply checks for a not zero ssf value: > > > https://github.com/openldap/openldap/blob/master/libraries/libldap/cyrus. > > > c#L745 > > > > That's an implementation detail we shouldn't rely on. > > Why? Since libldap is now part of wldap32 and GSSAPI SASL pluging is also > part of libldap now it's part of the implementation detail we can surely > rely on. We include it Wine but it's still code from an external project that we want to update when necessary. I'd rather avoid depending on how the value is used. Also note that the session key attribute was specifically added to GSSAPI to be compatible with SSPI. > > > > 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? Found it, max token size is 48256 for Negotiate and 48000 for Kerberos. > > > 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. -- 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.

Aug. 5, 2023

[Bug 55304] Kerberos authentication stopped to work after PE wldap32 conversion

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=55304 --- Comment #11 from Dmitry Timoshkov <dmitry(a)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. -- 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.

Aug. 5, 2023

[Bug 55304] Kerberos authentication stopped to work after PE wldap32 conversion

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=55304 --- Comment #10 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Hans Leidekker from comment #5) > (In reply to Dmitry Timoshkov from comment #3) > > (In reply to Hans Leidekker from comment #1) > > > I have replaced QueryContextAttributesA(SECPKG_ATTR_KEY_INFO) with > > > QueryContextAttributesA(SECPKG_ATTR_SESSION_KEY) after implementing the > > > attribute for Kerberos and NTLM. > > > > According to my testing Kerberos implementation under Windows 10 returns > > SEC_E_UNSUPPORTED_FUNCTION for > > QueryContextAttributes(SECPKG_ATTR_SESSION_KEY). > > What Windows version are you testing with? > > What about Negotiate? Do you have an idea how to test it? Apparently for a proper test it's necessary to create a connection, and once the connection is set up it's up to a backend (NTLM/Kerberos) to handle it. (In reply to Hans Leidekker from comment #6) > (In reply to Dmitry Timoshkov from comment #2) > > (In reply to Hans Leidekker from comment #1) > > > SSF is used by ldap_int_sasl_bind() to determine if the SASL security layer > > > should be used at all. This page documents it as representing the key size > > > for values > 1: > > > > > > https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/sasl.intro-44/ > > > index.html > > > > libldap simply checks for a not zero ssf value: > > https://github.com/openldap/openldap/blob/master/libraries/libldap/cyrus. > > c#L745 > > That's an implementation detail we shouldn't rely on. Why? Since libldap is now part of wldap32 and GSSAPI SASL pluging is also part of libldap now it's part of the implementation detail we can surely rely on. > > > 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. -- 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.

Aug. 5, 2023