http://bugs.winehq.org/show_bug.cgi?id=16013
--- Comment #17 from Juan Lang juan_lang@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?