On 3/29/22 14:05, Hans Leidekker wrote:
On Mon, 2022-03-28 at 14:01 +0300, Paul Gofman wrote:
- if (dwObjectType != CERT_QUERY_OBJECT_FILE)
- if (dwObjectType == CERT_QUERY_OBJECT_BLOB)
{
WARN("don't know what to do for type %ld embedded signed messages\n",
dwObjectType);
WCHAR temp_path[MAX_PATH], temp_name[MAX_PATH];
const CERT_BLOB *b = pvObject;
TRACE("cbData %lu, pbData %p.\n", b->cbData, b->pbData);
if (!GetTempPathW(MAX_PATH, temp_path) || !GetTempFileNameW(temp_path, L"blb", 0, temp_name))
{
ERR("Failed getting temp file name.\n");
return FALSE;
}
file = CreateFileW(temp_name, GENERIC_READ | GENERIC_WRITE, 0,
NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_DELETE_ON_CLOSE, NULL);
if (file == INVALID_HANDLE_VALUE)
{
ERR("Could not create temp file.\n");
SetLastError(ERROR_OUTOFMEMORY);
return FALSE;
It would be nice to avoid creating a temporary file. Perhaps we could factor out a helper that operates on memory and rewrite CryptSIPRetrieveSubjectGuid() to use a file mapping?
Well, I thought of that, but the callchain currently ends in imagehlp which doesn't work with memory by design. As the test on testbot shows, the blob is supported starting from Win7, which, as I understand, coincides with crypt32 / cryptsp / advapi dependencies redesign on Windows. My understanding is that to solve this sensibly without introducing temporary files is to redesign that as well without relying on imagehlp, and maybe wintrust now should rely on crypt32 / cryptsp and not vice versa. So this is a question of course if localized fixes like this is a step in the right direction overall, but I don't currently see to make it the other way before such a broad redesign.