The problem is, incredibly, a service defect within the Microsoft function WinVerifyTrust. (It shows up for Windows version 5.1 build 2600.xpsp_sp2_rtm.040803-2158: Service Pack 2, which presumably must be older than the known working build xpsp_sp2_qfe.070227-2300 identified in a Heath Stewart blog at MSDN).

My proposed solution is to provide a custom parameter to OOo Setup.exe (such as, /trusted) to enable a Microsoft flag which, according to MSDN, the function WinVerifyTrust subfunction MsiGetFileSignatureInformation uses to decide whether the result is reported as a fatal error or a warning that can be ignored. Scan the OOo setup component's final Windows source code for "MsiGetFileSignatureInformation" and if present then this solution should work. Alternatively, perhaps the proposed OOo Setup.exe /trusted parameter can be used to override the default action by deleting the cabinet entry in the MsiDigitalSignature table.

http://msdn2.microsoft.com/en-us/library/aa370121(VS.85).aspx details MsiGetFileSignatureInformation function

"Remarks

When requesting only the certificate context, an invalid hash in the digital signature does not cause MsiGetFileSignatureInformation to return a fatal error. To return a fatal error for an invalid hash, set the MSI_INVALID_HASH_IS_FATAL flag in the dwFlags parameter.

The certificate context and hash information is extracted from the file by a call to WinVerifyTrust. The ppcCertContext parameter is a duplicate of the signer certificate context from the signature. It is the responsibility of the caller to call CertFreeCertificateContext to free the certificate context when finished.

Note that MsiGetFileSignatureInformation requires the presence of the Wintrust.dll file on the system."

http://msdn2.microsoft.com/en-us/library/aa372835.aspx details Windows Installer error messages

As a part of the Open Protocol Specifications, the hex values for Win32 error codes can now be found at http://msdn2.microsoft.com/en-us/library/cc231199.aspx

http://msdn2.microsoft.com/en-us/library/aa388208(VS.85).aspx details WinVerifyTrust function

"[The WinVerifyTrust function is available for use in the operating systems specified in the Requirements section. It may be altered or unavailable in subsequent versions.]

The WinVerifyTrust function performs a trust verification action on a specified object. The function passes the inquiry to a trust provider that supports the action identifier, if one exists."

http://msdn.microsoft.com/en-us/library/ms721627(VS.85).aspx details trust provider

According to Heath Stewart's blog at MSDN:

"HRESULT 0x80092003 is CRYPT_E_FILE_ERROR, and Windows Installer logically errs on the side of caution and returns Windows Installer error message 1330.

Windows Installer error message 1330 can be returned when WinVerifyTrust() - a security check that validates the digital signature against a file - fails to read the entire file.

[Similarly] error message 1335 is returned by Windows Installer when Windows Installer itself couldn't read the entire file and since it isn't a security issue, it retries 5 times before failing.

The difference is whether or not the cabinets are signed - a requirement for shipping a product: all file types that accept an Authenticode signature must be signed. Windows Installer runs cabinets through WinVerifyTrust() if there is an entry in the MsiDigitalSignature table for them."

The error message 1330 dialog I got was spied (via MSI logging parameters "voicewarmup") to be the HRESULT 0x800B010E followed by an error 270 returned by WinVerifyTrust for openofficeorg1.cab version 3.1.

Previously I never allowed automatic updates by Microsoft. After this error I recently allowed auto updates and upgraded to MSI 4.5, all to no avail (Build 2600.xpsp_sp2_gdr.090206-1233). I refuse to upgrade further to SP3 which may or may not have addressed this problem. It is disgusting!!! According to another software engineer experiencing this same problem but when trying to install Microsoft's own Visual Studio 2008:

"If you ask me, in the year 2008, we should NOT be seeing issues like "files not being fully read", especially of this size (Mb not Gb), and when they are stored on a local HDD. Clearly there is a weakness in the code that is reading these CAB files."