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

[Bug 60234] New: crypt32: PFXImportCertStore does not set ERROR_INVALID_PASSWORD on a wrong password

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60234 Bug ID: 60234 Summary: crypt32: PFXImportCertStore does not set ERROR_INVALID_PASSWORD on a wrong password Product: Wine Version: 11.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: crypt32 Assignee: wine-bugs(a)list.winehq.org Reporter: nayuta65535(a)gmail.com Target Milestone: --- Distribution: --- When PFXImportCertStore is given the wrong password it correctly returns NULL, but does not set a last error, so the caller cannot tell why the import failed. Windows: returns NULL, GetLastError() == ERROR_INVALID_PASSWORD (0x56) Wine: returns NULL, GetLastError() unchanged from before the call Tested on an unmodified wine-11.16 build (fresh prefix, no DLL overrides) against Windows 11 on the same machine, using the same binary. Reproduce with any PKCS#12 blob and a deliberately wrong password. -- 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. 24, 2026

[Bug 60233] New: crypt32: PFXVerifyPassword always returns FALSE, even for the correct password

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60233 Bug ID: 60233 Summary: crypt32: PFXVerifyPassword always returns FALSE, even for the correct password Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: crypt32 Assignee: wine-bugs(a)list.winehq.org Reporter: nayuta65535(a)gmail.com Target Milestone: --- Distribution: --- PFXVerifyPassword returns 0 for every input I have tried, including passwords that PFXImportCertStore then accepts for the same blob. Windows returns 1 for the same calls. Tested on an unmodified wine-11.16 build (fresh prefix, no DLL overrides), and on Windows 11 on the same machine using the same binary. Seven PKCS#12 blobs, varying the encryption scheme and whether a private key is present: Wine returns 0 for all seven, Windows returns 1 for all seven. Since PFXImportCertStore succeeds on the same blob with the same password, the password itself is being handled correctly elsewhere. To reproduce without any custom tooling: openssl req -x509 -newkey rsa:2048 -nodes -keyout k.pem -out c.pem \ -subj /CN=test openssl pkcs12 -export -in c.pem -inkey k.pem -out test.pfx \ -passout pass:winetest then call PFXVerifyPassword with that blob and L"winetest". -- 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. 24, 2026

[Bug 60232] advapi32: GetCurrentHwProfileA crashes on a NULL argument, and the profile guid is hardcoded

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60232 nayuta65535(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Component|crypt32 |advapi32 -- 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. 24, 2026

[Bug 60232] advapi32: GetCurrentHwProfileA crashes on a NULL argument, and the profile guid is hardcoded

by WineHQ Bugzilla

Aug. 24, 2026

[Bug 60232] crypt32: GetCurrentHwProfileA crashes on a NULL argument, and the profile guid is hardcoded

by WineHQ Bugzilla

Aug. 24, 2026

[Bug 60232] New: GetCurrentHwProfileA crashes on a NULL argument, and the profile guid is hardcoded

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60232 Bug ID: 60232 Summary: GetCurrentHwProfileA crashes on a NULL argument, and the profile guid is hardcoded Product: Wine Version: 11.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: advapi32 Assignee: wine-bugs(a)list.winehq.org Reporter: nayuta65535(a)gmail.com Target Milestone: --- Distribution: --- GetCurrentHwProfile is still the semi-stub added in 2002. Four separate problems, all reproduced on an unmodified wine-11.16 build (../configure --enable-archs=i386,x86_64, fresh prefix, no DLL overrides), compared against Windows 11 on the same machine using the same binary. 1. GetCurrentHwProfileA(NULL) crashes. wine: Unhandled page fault on write access to 0000000000000000 at address 00006FFFFF1E3F38 There is no NULL check, so the first write to pInfo->dwDockInfo faults. Windows returns FALSE and sets ERROR_INVALID_PARAMETER (0x57). 2. The profile guid is a constant compiled into Wine, so every installation reports the same machine identity: Wine: {12340001-1234-1234-1234-123456789012} Windows: {7572da61-84c6-11f0-a00e-806e6f6e6963} Applications use this value to identify the machine they are running on. 3. GetCurrentHwProfileW always returns FALSE. On Windows it succeeds and returns values matching the A version. 4. dwDockInfo is DOCKINFO_DOCKED (0x2). On the Windows machine it is DOCKINFO_UNDOCKED (0x1). On Windows the profile lives at HKLM\System\CurrentControlSet\Control\IDConfigDB\Hardware Profiles\0001 HwProfileGuid = "{7572da61-84c6-11f0-a00e-806e6f6e6963}" FriendlyName = "Undocked Profile" with CurrentConfig, CurrentDockInfo\DockingState, AcpiAlias\0001 and a Hardware Profiles\0000 template alongside it. The guid there is a version 1 UUID whose timestamp is 2025-08-29, matching when Windows was installed on this machine, which supports MSDN's statement that the system generates it at install time. Its node field is the fixed value 806e6f6e6963 rather than a MAC address. Bug 4468 covers the same stub but was closed as FIXED once Full Tilt Poker started working again; the commit recorded there (eb48a472) only corrects a typo in the hardcoded guid string, which had one hex digit too many for five years. The function itself was never implemented. Bug 4468 Comment #12 on that bug already describes the NULL crash and outlines what a real implementation would need to do. -- 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. 24, 2026

[Bug 45746] Import pfx fails. Metatrader 5 cannot connect to broker

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=45746 nayuta65535(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nayuta65535(a)gmail.com --- Comment #13 from nayuta65535(a)gmail.com --- This looks fixed as well. The reproducer in comment #8 (wine control -> Internet Options -> Content -> Certificates -> Import -> pick a .pfx -> "file not recognized") goes through CryptQueryObject to work out the file type. Support for PFX objects was added there in 962aed51205 ("crypt32: Add support for PFX objects in CryptQueryObject."), first released in wine-4.1 - after the 3.14 this was reported against. I tested on an unmodified wine-11.16 build (fresh prefix, no DLL overrides, builtin crypt32). CryptQueryObject with CERT_QUERY_CONTENT_FLAG_ALL returns TRUE and reports CERT_QUERY_CONTENT_PFX for PKCS#12 blobs, and PFXImportCertStore imports them. Worth noting that comment #0 mentions installing native crypt32 through winetricks. That should not be necessary, and it changes the behaviour being tested here. I do not have the broker-specific MetaTrader 5 certificate, so I cannot confirm that application's symptom directly. -- 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. 24, 2026

[Bug 42383] certmgr.exe is unable to import certificate in PKCS12 format

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=42383 nayuta65535(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nayuta65535(a)gmail.com --- Comment #2 from nayuta65535(a)gmail.com --- This looks fixed. The trace in comment #1 shows: warn:crypt:CryptQueryObject unimplemented for types 00001000 0x1000 is CERT_QUERY_CONTENT_FLAG_PFX (1 << CERT_QUERY_CONTENT_PFX). Support for PFX objects was added to CryptQueryObject in 962aed51205 ("crypt32: Add support for PFX objects in CryptQueryObject."), which first shipped in wine-4.1 - after the 2.1 this was reported against. CERT_QUERY_CONTENT_FLAG_PFX is no longer part of the unimplementedTypes mask in dlls/crypt32/object.c, so that warning can no longer be emitted for a PFX blob. I tested on an unmodified wine-11.16 build (../configure --enable-archs=i386,x86_64, fresh prefix, no DLL overrides). CryptQueryObject called with CERT_QUERY_CONTENT_FLAG_ALL returns TRUE and reports CERT_QUERY_CONTENT_PFX (12) for PKCS#12 blobs - certificate-only ones included, and ones encrypted with the legacy pbeWithSHAAnd40BitRC2-CBC scheme. I do not have certmgr.exe from VS2017, so I have not reproduced the original symptom end to end; someone who has it may want to confirm before this is closed. -- 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. 24, 2026

[Bug 60231] New: WinVerifyTrust/CryptMsgControl(CMSG_CTRL_VERIFY_SIGNATURE) rejects valid Authenticode signatures whose authenticatedAttributes don't survive re-encoding round-trip

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60231 Bug ID: 60231 Summary: WinVerifyTrust/CryptMsgControl(CMSG_CTRL_VERIFY_SIGNAT URE) rejects valid Authenticode signatures whose authenticatedAttributes don't survive re-encoding round-trip Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: crypt32 Assignee: wine-bugs(a)list.winehq.org Reporter: digitallyremastered128(a)gmail.com Target Milestone: --- Distribution: --- CSignedMsgData_UpdateAuthenticatedAttributes() in dlls/crypt32/msg.c re-encodes a SignerInfo's authenticatedAttributes from the decoded CRYPT_ATTRIBUTES representation (via CryptEncodeObjectEx(PKCS_ATTRIBUTES, ...)) before hashing it, even when *verifying* a signature (as opposed to creating one). Per RFC 2315/PKCS#7, what actually gets hashed for signature verification purposes is the DER encoding of authenticatedAttributes exactly as the signer originally produced it (re-tagged from [0] IMPLICIT to a universal SET, content octets otherwise untouched) - not an independent re-encoding produced by decoding into this library's own internal structure and re-serializing it. Re-encoding an arbitrary already-decoded ASN.1 structure is not guaranteed to byte-for-byte reproduce what the original signer encoded, particularly for opaque/vendor-specific attributes this generic encoder has no precise custom handling for (e.g. Microsoft's SPC_SP_OPUS_INFO attribute, used in every Authenticode signature). When the round-trip doesn't match, the hash computed here diverges from the one actually covered by the RSA signature, and verification is incorrectly reported as failed - even though the RSA signature itself decrypts correctly and the file's actual content digest matches what's embedded in the signature. Reproduction: Any Authenticode-signed PE file whose signer's authenticatedAttributes don't happen to round-trip identically through Wine's re-encoder will fail verification. A concrete, currently-reproducible example: - Download FL Studio 26.1.4.5589's installer or the FLEngine_x64.dll it installs (Image-Line, https://www.image-line.com - signed under a current "Image Line NV" certificate). - Under Wine, either: (a) run FL64.exe - it shows "The validity of the program could not be verified. Please reinstall it and try returns TRUST_E_CERT_SIGNATURE (0x80096004). - The same application's earlier build (e.g. 24.2.2.4597 or 25.2.5.5319, signed under Image-Line's previous certificate) verifies successfully with the exact same Wine build - confirming this is about the specific file's signature encoding, not Wine's general Authenticode support, RSA/crypto math, or the certificate's key size. Root-cause investigation: Traced with live debugging (breakpoints on RSAENH_CPVerifySignature and hash_file_data, register/memory inspection) confirmed, in order: 1. The RSA public-key decrypt operation (via the vendored SymCrypt library) succeeds and produces valid PKCS#1 v1.5-padded output - RSA math itself is not the problem. 2. The PE-content hash (SOFTPUB_HashPEFile) is computed with fully correct boundaries and matches the actual embedded SpcIndirectDataContent.digest field exactly (verified independently via direct ASN.1 inspection) - the file-content hashing is not the problem either. 3. The mismatch is specifically between CSignedMsgData_UpdateAuthenticatedAttributes's re-encoded-attributes hash and the RSA-decrypted value, which is the hash of the original authenticatedAttributes bytes. A patch is ready (preserves the original encoded SignedData bytes at decode time and hashes the original authenticatedAttributes bytes directly instead of re-encoding, falling back to the previous behavior if anything about the original bytes doesn't parse as expected). Verified fixed against the file above with no regression on the previously-working build, Wine's own crypt32 msg.c test suite (1026 tests, 0 failures), and additionally checked against Google Chrome's and Mozilla Firefox's own signed executables (both continue to verify correctly). Will link the merge request here once opened. -- 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. 24, 2026

[Bug 60229] Netscape Navigator 3.04 for Windows 3.1 crashes on start on a null pointer

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60229 Alex Henrie <alexhenrie24(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch --- Comment #1 from Alex Henrie <alexhenrie24(a)gmail.com> --- Patch sent: https://gitlab.winehq.org/wine/wine/-/merge_requests/11740 -- 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. 24, 2026