On Wed Jan 8 16:33:10 2025 +0000, Paul Gofman wrote:
Besides what Hans mentioned (the bug concerns CRL verification which I am not touching here and not OCSP) it seems weird if the application uses CERT_VERIFY_CACHE_ONLY_BASED_REVOCATION and then depends firmly on that check to succeed (as in not returning _REVOCATION_OFFLINE). The dependency on a certificate being frequently checked outside of the app is weird by itself, wonder what that cert is so it is supposed to be guaranteed to be checked just by Windows boot. Even if certificate is frequently checked (even, e. g., by Windows itself on boot), the cached revocation status can be invalidated any time (due to expiration or due to cache cleanup, the cache is AppDataLow), so that should be sometimes failing on Windows too. So it seems to me that the bug (if still valid??) could use a bit more exploration. Maybe something else is going wrong. First check would be clearing certificates revocation cache on Windows right before running the program (e. g., between the lines of this: https://mssec.wordpress.com/2013/04/09/delete-local-crl-cache-in-windows/). If success really depends solely on the cert revocation check being present in cache (which I doubt a bit and suspect there might be more to it) and that certificate is really something Windows always checks on boot at least then maybe the correct (while unfortunate) solution would be to think of some way of pre-populating the cache of select certificates on Wine boot. Or the program is just frequently broken on Windows too.
I took a look at Bug 56559 and found that the actual problem seems to be in CertVerifyCertificateChainPolicy() (not handling the related flags specified by the launcher to ignore revocation errors), while revocation errors themselves can easily happen on Windows too. I dropped a comment there and probably going to prepare a separate patch for that.