https://bugs.winehq.org/show_bug.cgi?id=50721
Bug ID: 50721
Summary: IDA Pro 7.5: Lumina can't contact server, complains
about Schannel security attributes
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: secur32
Assignee: wine-bugs(a)winehq.org
Reporter: thotypous(a)gmail.com
Distribution: ---
Using Wine Staging, IDA Pro fails to contact the Lumina server when trying to
do any operation that depends on it (e.g. Lumina menu -> Pull All Metadata).
The IDA's output window shows "lumina: Schannel does not support the requested
security attributes"
By tracing secur32, it turns out that InitializeSecurityContextA is being
called with fContextReq flags ISC_REQ_EXTENDED_ERROR and
ISC_REQ_MANUAL_CRED_VALIDATION, which are not handled by Wine:
00f4:trace:secur32:InitializeSecurityContextA 0x3436e40 0x3436e50 (null)
0x0008c110 0 0 0x529b58 0 (nil) 0x529af8 0x3436e9c (nil)
Now regarding each flag:
1. ISC_REQ_EXTENDED_ERROR: according to MSDN, this flag means "When errors
occur, the remote party will be notified."
However, modern TLS does not have any mechanism to notify the remote party
about errors. Thus it seems unlikely that this flag causes any difference in
behavior, at least when the remote party is not running Microsoft's TLS
implementation.
When researching about the flag, I found
https://mskb.pkisolutions.com/kb/975858, which states Windows 7 used to ignore
this flag, but since it caused issues with some applications, they changed
schannel to return ISC_RET_EXTENDED_ERROR (via pfContextAttr) when the flag is
set. The KB does not describe any other change deployed by the upgrade. This
fact further supports the hypothesis that the flag does not change the behavior
of the protocol.
In short, up-to-date Windows 7 seems to just return ISC_RET_EXTENDED_ERROR when
ISC_REQ_EXTENDED_ERROR is set, but otherwise ignores it.
2. ISC_REQ_MANUAL_CRED_VALIDATION: according to MSDN, this flag means "By
default, Schannel validates the server certificate by calling the
WinVerifyTrust function; however, if you have disabled this feature using the
ISC_REQ_MANUAL_CRED_VALIDATION flag, you must validate the certificate provided
by the server that is attempting to establish its identity."
However, Wine currently does not carry automatic server certificate validation
at all. The OSX implementation always calls "SSLSetEnableCertVerify(s->context,
FALSE)" to disable it explicitly. The GnuTLS implementation never calls
"gnutls_session_set_verify_cert", which would be required to enable server
certificate validation.
Strictly speaking, the current implementation of Schannel in Wine is insecure,
but fixing it would require more extensive changes to the code and could cause
regression bugs with other applications. Thus, I argue it should be dealt with
by another bug entry and fixed by another patch.
Therefore, the attached patch restricts itself to return
ISC_RET_MANUAL_CRED_VALIDATION when ISC_REQ_MANUAL_CRED_VALIDATION is set, and
to better document the current situation in the code.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=45032
Bug ID: 45032
Summary: WineTest does not run the vcomp tests
Product: Wine
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: vcomp
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
So WineTest is not running the vcomp tests. What happens is this:
* It parses the vcomp_test.exe filename and concludes that this tests the vcomp
dll.
* It does a LoadLibraryExA("vcomp.dll", NULL, LOAD_LIBRARY_AS_DATAFILE) which
fails (as expected) and concludes that the dll is missing:
vcomp=dll is missing
* Since the dll is missing WineTest skips the vcomp tests.
According to Dan Kegel (see bug 31609) this is a manifest / activation context
issue and he sent a patch for it [1]. However the patch was for the TestBot
[2], not WineTest, and as far as I can tell it's not working.
Furthermore WineTest already has activation context code that seems equivalent
to Dan Kegel's patch.
Note that not all VMs have vcomp.dll. Based on the current results the 32 bit
dll is present on the TestBot's w2000pro, wxppro, w2003std, wvistau64*,
w2008s64, w8, w864 VMs and the 64 bit one is present on wvistau64, w2008s64 and
w864.
Note that some online resources seem to imply that vcomp.dll is present in the
Visual C++ 2005 redistributable (and VC++ 2005 was indeed installed on all the
VMs that have vcomp.dll except w2008s64 (though maybe it was installed and it
was not written down)). Some VMs seem to have other versions such as
vcomp90.dll but not vcomp.dll.
[1] https://bugs.winehq.org/show_bug.cgi?id=31609https://www.winehq.org/pipermail/wine-patches/2012-September/117631.html
[2] Paradoxically the TestBot has no problem running the vcomp tests now that
they dynamically load the vcomp dll. That's because the TestBot makes no
assumption based on the executable filename since one can upload test binaries
that don't follow any naming scheme. So now that the test dynamically loads
vcomp.dll the TestBot cannot check for it.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=50836
Bug ID: 50836
Summary: dxva2api.h does not compile as C++
Product: Wine
Version: 6.4
Hardware: x86-64
OS: Windows
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: dxva2
Assignee: wine-bugs(a)winehq.org
Reporter: bjoern(a)hazardy.de
The functions do not compile with g++ 10:
error: invalid conversion from 'void*' to 'DXVA2FixedToFloat::<unnamed
struct>*' [-fpermissive]
The functions are broken since
https://source.winehq.org/git/wine.git/commitdiff/6aeb891d529d821fa62e26c17…
On MinGW it was fixed once, but now they reimport the library from wine and it
broke in
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/c0fa4d755413c4541bdad32f07…
again.
This hinders compiling Qt on Windows with GCC.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=34906
Bug #: 34906
Summary: [regres] Zoo Tycoon: closed on start in 1.7.6
Product: Wine
Version: 1.7.6
Platform: x86
OS/Version: FreeBSD
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: fiziologus(a)gmail.com
Classification: Unclassified
closed without crash after begin music.
in console:
fixme:imm:ImmReleaseContext (0x2006a, 0x14f250): stub
fixme:imm:ImmGetOpenStatus (0x14f250): semi-stub
fixme:win:EnumDisplayDevicesW ((null),0,0x32ed38,0x00000000), stub!
fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to
16
err:quartz:GetClassMediaFile Media class not found
err:quartz:GetClassMediaFile Media class not found
err:quartz:GetClassMediaFile Media class not found
err:quartz:GetClassMediaFile Media class not found
fixme:d3d_surface:wined3d_surface_flip Ignoring flags 0x1.
fixme:d3d:wined3d_device_set_render_target Surface 0x1ae5c0 doesn't have render
target usage.
err:ddraw:d3d_device_init Failed to set render target, hr 0x8876086c.
result regression test (1.6-good, 1.7.6-bad)
3fb53e21fb2cccf249ed65a4641eac21422f6609 is the first bad commit
commit 3fb53e21fb2cccf249ed65a4641eac21422f6609
Author: Henri Verbeet <hverbeet(a)codeweavers.com>
Date: Tue Sep 17 09:22:37 2013 +0200
ddraw: Don't set render target / depth stencil usage on sysmem surfaces.
Setting render target usage on a P8 surface for example would fail surface
creation, while such surfaces can't be used for actual rendering anyway.
Tests
confirm that surface creation is supposed to succeed for P8 surfaces with
both
DDSCAPS_SYSTEMMEMORY and DDSCAPS_3DDEVICE set.
:040000 040000 578fd201cb41a75b478b47c58c7a0a1a9b6a5209
38c723fb112690d758c0868debec68b3b61c4510 M dlls
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.
https://bugs.winehq.org/show_bug.cgi?id=50783
Bug ID: 50783
Summary: WineTest declares dlls with dots in their name as
missing
Product: Wine
Version: 6.3
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: testcases
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
It turns out that winetest.exe has been checking the presence of the
dlls by calling LoadLibrary("serialui") and not
LoadLibrary("serialui.dll"). Surprisingly this works.
But if the dll name contains dots, such as "lib.and.dot.dll", then
LoadLibrary("lib.and.dot") does not work, even if lib.and.dot.dll does exist,
as confirmed by LoadLibrary("lib.and.dot.dll"). At least in Wine.
So this causes winetest.exe to skip the lib.and.dot tests because the dll is
missing.
Maybe that's a LoadLibrary() Wine bug.
Or maybe the fix would be to add the '.dll' extension... except if the name
from
the test executable ends in .exe, .com, .ocx, etc. But this would require a
list of authorized library extensions (or do the checks twice: once without and
once with the extra .dll extension).
lib.and.dot_test.exe -> lib.and.dot.dll
msscript.ocx_test.exe -> msscript.ocx
serialui_test.exe -> serialui.dll
reg.exe_test.exe -> reg.exe (yes WineTest calls LoadLibrary("reg.exe"))
chcp.com_test.exe -> chcp.com
ndis.sys_test.exe -> ndis.sys
...
Or change the test executable filenames so they always have the full name of
the tested dll.
Or this could be fixed by not doing the LoadLibrary() check at all:
https://bugs.winehq.org/show_bug.cgi?id=45032#c1
--
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.
https://bugs.winehq.org/show_bug.cgi?id=50738
Bug ID: 50738
Summary: Guild Wars 2 launcher can't login
Product: Wine
Version: 6.3
Hardware: x86-64
URL: https://account.arena.net/content/download/gw2/win/64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: sven.wine(a)gmail.com
Regression SHA1: 8f50dde9cd3f4ea7856106f5b1691827d4cf8713
Distribution: Ubuntu
Created attachment 69508
--> https://bugs.winehq.org/attachment.cgi?id=69508
Log from 8f50dde9cd3f4ea7856106f5b1691827d4cf8713 with
+timestamp,+pid,+tid,+seh
Since
commit 8f50dde9cd3f4ea7856106f5b1691827d4cf8713
Author: Jacek Caban <jacek(a)codeweavers.com>
Date: Mon Feb 15 21:57:42 2021 +0100
ntdll: Store entire XMM context in x86_64 syscall frame.
the Guild Wars 2 launcher can't reach login the server anymore. Attached is the
log at 8f50dde9cd3f4ea7856106f5b1691827d4cf8713. I confirmed that with
8f50dde9cd3f4ea7856106f5b1691827d4cf8713^ everything was working as expected.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=50034
Bug ID: 50034
Summary: In font dialog's sample text, background changes color
Product: Wine
Version: 5.19
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: comdlg32
Assignee: wine-bugs(a)winehq.org
Reporter: whydoubt(a)gmail.com
Distribution: ---
When the font dialog is first opened, the background behind the sample text is
a different color than the rest of the sample area. As soon as a change is
made in font selection, this condition is corrected.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=45685
Bug ID: 45685
Summary: regression caused in running Dragon NaturallySpeaking
12.5
Product: Wine
Version: 3.14
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: susancragin(a)earthlink.net
Distribution: ---
Created attachment 62107
--> https://bugs.winehq.org/attachment.cgi?id=62107
terminal output with no winedebug running
Dragon NaturallySpeaking 12.5 installs well in wine 3.14 (Staging).
It also goes through training.
But then it crashes when I try to run it for the first time.
--
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.