Ok looks like I partially lied, it’s actually 2 patches to cryptopp (not 1) and they’ll never accept the second one since I’m basically patching out a powerup self test (that the author says is deprecated and shouldn’t be used anyway). So we’ll have to figure out how to gracefully satisfy cryptopp/fipstest.cpp at master · weidai11/cryptopp · GitHub to get a fully upstreamed fix. Until then we’ll have to build cryptopp and replace the DLL everytime the launcher updates.
Basically I have no idea why the FIPS dll is trying to test/verify itself, fips certification was removed in 2014 according to the author. They might have some details though.
Looks like a downstream patch is viable, as this undocumented “feature” is being used in other applications which also error on Wine … i’ll give the wine patch a go tomorrow evening if time permits i’ve got the environment setup for applying patches and recompiling on that machine so should be easy to test but i won’t have the skills for working out other places to apply the needed code.
Yeah Wine can fix the first issue by linking to msvcrt, but the powerup self test patch will still be needed and is unlikely to get accepted into cryptopp. We’d basically need to figure out why we’re hitting that self test anyway and see if there is a way around it without just hacking it out like I did
My guess would be wine isn’t linking or starting something the library is expecting to finish the SetPowerUpSelfTestInProgressOnThisThread call
My first port of call would be to dig through that call and see what it’s expecting or relying on to set g_powerUpSelfTestStatus to POWER_UP_SELF_TEST_PASSED internally (i’m guessing that’s what happens on a working windows run of the code…
I think we are best to get the msvcrt linking/loading patch tested and confirmed in wine first, then determine why cryptopp’s FIPS self test is failing inside Wine, best guess is a missing or unsupported Algo in GnuTLS.
Like i said in github issues, i might be completely wrong here as i’m no C developer but i debug code all day long so hopefully some of that might be useful
Wine doesn’t currently load msvcrt automatically when needed by another lib whereas windows does some undocumented magic (if i’ve understood this correctly). There are a number of applications/libraries which rely on this implementation so it looks like a Wine patch for this issue is definitely a possible.
Second issue seems to be the cryptopp library is failing a FIPS “self test” which we are tracking down and testing here: Eve Crash - Self test returning a non POWER_UP_SELF_TEST_PASSED status in wine · Issue #1 · Algebro7/cryptopp · GitHub if you have any expertise on this please feel free to join in. My best guess at the moment is a cryptography algo being using in the launcher for the new oAuth credential storage isn’t supported by Wine’s GnuTLS implementation of the windows calls. Might be helpful to know what hashing / cryptography algo is being used so we can look into which calls are missing in wine’s implementation.
There is a patched version for the dll which skips the self test by @Renard_DuGaulle in an above post and appears to work fine once included in the launcher. But this is far from ideal and i’m not sure if it should be recommended. This does appear to indicate the “FIPS self test” is failing but actual cryptography / hashing of the credentials is working?
My opinion on replacing the DLL is it should be fine as all we are doing is disabling a check on supported algos for hashing credentials in a low level lib, which should have zero impact on the game and it’s not trying to “hack or cheat”. However i’m not condoning anyone actually using this method, i’d rather we get this fixed properly, editing libraries or framework code always causes a maintenance issue going forward (like having to replace this dll each launcher update).
So there we go, hopefully some fixes inbound and i’ll add a wine-staging patch to my repo soon™ for the first issue. The second issue could take a while longer to locate and fix.
The DLL is being removed soon and the cryptopp maintainer said he would like to reach out to the launcher team to help them set it up correctly without using the DLL. He noted that this change to remove the DLL is going to impact Windows users too, not just Linux, so it’s something he recommends that CCP gets resolved. It should also in theory fix all the problems we’re having.
It’s all about trusting the algorithm hasn’t been corrupted or badly implemented. Before first use, a FIPS140-2 device goes through a challenge and response mechanism comparing the library output with a known “good” implementation. And yes, the implication is that there is a suitable “known good” implementation to assess against.
Basically: without it how do you know the cryptographic system hasn’t been tampered with?
This only applies for FIPS140-2 and above (FIPS140-1 doesn’t mandate it). This is what you would expect if the library was to be implemented within a dedicated network crypto device - there will be additional things around the physical hardening of that device as well.
FIPS140-2 worries about “tamper detection” rather than “tamper resistance” (which is in FIPS140-3).
Cryptopp was moved out of the current FIPS140 lists in 2016. Certification only included version 5.3.0 Cryptographic Module Validation Program | CSRC which is now out of support.
(and the test config was Windows XP!)
From a quick dirty read: There’s a flag set at compile time in cryptopp that enables FIPS140-2 mode - without this set it doesn’t compile in the FIPS140-2 tests. That means it’s not FIPS140-2 compliant any more, but as the certification has expired it isn’t anyway, and the certificate never covered versions later than 5.3.0.
This is about trust and assurance - which is the hard bit of security.
Well, I opened a support ticket with ATTN: CCP Cemetary as @CCP_Cemetery suggested, but the support staff pretty much just shot it down and said they are not planning to figure anything out or reach out to anyone to get it resolved, even when it impacts Windows as the cryptopp maintainer said it would. I’ll keep trying but just wanted to give that update.
Got another update, they’re simply not going to do anything (or forward the ticket to @CCP_Cemetery) until it’s broken on Windows. Looks like we’re on our own A PR will likely be merged into Cryptopp, but that will require CCP to upgrade to the next version of cryptopp when it is released, so a wine patch is our best bet. One of the wine maintainers provided us an untested patch that we’re working on testing but I would expect that to take awhile.
If CCP wouldn’t care at all they would not have had this discussion with us. I know that sometimes product management and helping customer is a delicate thing - like in this case - where you simply can‘t do any official help, but you can help unofficial without out being able to talk about it for juristical reasons.
At the moment things look promising, so let’s hope for a WINE fix.
I find ironic that Vapor Alpha Ware StarCitizen found a way to get in touch with the winedevs directly and make the game work there, and somehow CCP cant get bothered to try the same. They got Apple to help them, but I have a feeling it didnt come cheap.
i’ve got the environment setup for applying patches and recompiling on that machine so should be easy to test but i won’t have the skills for working out other places to apply the needed code.
A PR will likely be merged into Cryptopp, but that will require CCP to upgrade to the next version of cryptopp when it is released, so a wine patch is our best bet. One of the wine maintainers provided us an untested patch that we’re working on testing but I would expect that to take awhile.