On Wed Jan 8 16:33:10 2025 +0000, Aida Jonikienė wrote:
Then, the core problem I think which might be the major trigger of the
issues on some instances is that the certificate revocation check is invoked with CERT_VERIFY_CACHE_ONLY_BASED_REVOCATION, but we ignore that in OCSP Wouldn't respecting the cache-only flag cause side effects though (as seen in https://bugs.winehq.org/show_bug.cgi?id=56559 and Rustup/Discord updater)?
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.