http://bugs.winehq.org/show_bug.cgi?id=16013 --- Comment #17 from Juan Lang <juan_lang(a)yahoo.com> 2009-01-07 11:37:32 --- (In reply to comment #16)
Here's a +crypt log from running 'makecat /cat winetest.cdf'. Contents of this file can be found in dlls/wintrust/tests/crypt.c.
I used native wintrust + builtin mscat32 with one more function forwarded to wintrust: CryptCATCDFEnumMembersByCDFTag.
Thanks. I forgot that native wintrust doesn't work with builtin crypt32 when encoding/decoding asn.1, because builtin crypt32 doesn't use msasn1. Sigh. Still, a few clues: trace:crypt:CryptSIPRetrieveSubjectGuid (L".\\winetest.cdf" (nil) 0x32fe38) (snip) trace:crypt:CryptSIPLoad ({de351a42-8e59-11d0-8c47-00c04fc295ee} 0 0x32f9e4) How the heck did that succeed? Perhaps native wintrust has a fallback if CryptSIPRetrieveSubjectGuid fails. crypt32 needs some tests added to see if it should identify CDF files or not. trace:crypt:CryptSIPCreateIndirectData (0x32f994 0x32fe4c (nil)) That's currently a stub in wintrust. Bug 16420 needs this too, though the implementation will likely differ for PE files and CDF files. trace:crypt:CryptMsgEncodeAndSignCTL (00010001, 0x32fe18, 0x32fe60, 00000000, (nil), 0x32fe90) I just added an implementation of that. So, at a quick glance, the crypt32 message stuff looks okay, it's mainly wintrust that needs work to create cat files. What happens with builtin wintrust and native mscat32? -- 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.