[Bug 49515] New: Star Wars: The Old Republic unable to patch on Debian but works on Mint
https://bugs.winehq.org/show_bug.cgi?id=49515
Bug ID: 49515 Summary: Star Wars: The Old Republic unable to patch on Debian but works on Mint Product: Wine Version: 5.12 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: toad@amphibian.dyndns.org Distribution: ---
Created attachment 67644 --> https://bugs.winehq.org/attachment.cgi?id=67644 Wine log of running the launcher
The SWTOR launcher is unable to patch itself, or to patch the game, and hence refuses to start the game even if it is actually up to date. However, it works on Linux Mint 19.3 (with the Xenial packages; the recommended bionic packages do not install).
Debug output from Wine is not obviously helpful. Logs from SWTOR show an UnzipFailed error which is suspicious. Wine logs show nothing obviously helpful.
I am using all the usual precautions for SWTOR: - Run the original installer in wine-devel. The installer does not work with staging. However, the patcher has the same issues on both. - On an affected system, the launcher hangs trying to patch itself, with errors in the SWTOR log. This can be fixed using the launcher repair utility. On Mint, it shows a bunch of assertion error dialogs, and works. - Login and accept the EULA, at this point it will complain about BitRaider. Exit and modify launcher.settings as usual to turn off BitRaider. - At this point, on Mint, Wine 5.11 is downloading the game successfully. On any version of Debian, it shows the error "Unable to retrieve patch data. Please check network connection. (206)". The TOR log shows the unzip error. I think the unzip error and the problems with the patcher patching itself are probably the same bug.
This stopped working around the time of Wine 5.10, I think because of an update to the launcher. It does not work on Debian 9, 10 or 11 on staging 5.11. On Debian 11, it does not work on staging 5.11 or devel 5.12.
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #1 from Matthew Toseland toad@amphibian.dyndns.org --- Created attachment 67645 --> https://bugs.winehq.org/attachment.cgi?id=67645 SWTOR log
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #2 from Matthew Toseland toad@amphibian.dyndns.org --- Wine staging 5.1, 5.8, 5.10 and 5.11, and at least Wine devel 5.12, all get the same error.
https://bugs.winehq.org/show_bug.cgi?id=49515
Matthew Toseland toad@amphibian.dyndns.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #67645|SWTOR log |SWTOR log (failing) description| |
https://bugs.winehq.org/show_bug.cgi?id=49515
Matthew Toseland toad@amphibian.dyndns.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |toad@amphibian.dyndns.org
https://bugs.winehq.org/show_bug.cgi?id=49515
Matthew Toseland toad@amphibian.dyndns.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Debian Hardware|x86 |x86-64
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #3 from Matthew Toseland toad@amphibian.dyndns.org --- Linux Mint 20 works with the focal packages.
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #4 from Matthew Toseland toad@amphibian.dyndns.org --- With the focal packages on Linux Mint 20, we don't get the assertion errors either.
https://bugs.winehq.org/show_bug.cgi?id=49515
Paul Gofman pgofman@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman@codeweavers.com
--- Comment #5 from Paul Gofman pgofman@codeweavers.com --- I've tested the issue. The game fails to verify a downloaded patch file with WinVerifyTrust because the root CA is absent on Debian 10 (""VeriSign Class 3 Public Primary Certification Authority - G5").
This have probably something to do with [1]. Brief search told me that VeriSign recommended some of their certificates for removal from browsers. But probably it is still there on Windows and other distributions. I can guess when it will be removed on Windows the launcher will have to use something else. Adding the certificate by the following sequence fixes the issue:
a. Copying certificate data from [2] to 'cert.crt'. b. cp cert.crt /usr/local/share/ca-certificates/extra/ c. update-ca-certificates
1. https://launchpad.net/debian/+source/ca-certificates/+changelog 2. https://knowledge.digicert.com/solution/SO5624
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #6 from Matthew Toseland toad@amphibian.dyndns.org --- Thank you! I get a different error now. :( It looks like it's trying to fetch download.solidconfig from localhost i.e. from BitRaider, even though I've turned BR off. Probably a game issue, will investigate further.
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #7 from Matthew Toseland toad@amphibian.dyndns.org --- download.solidconfig is an executable signed with Thawte Code Signing CA - G2. I wonder if a similar problem here?
I have no idea where Wine keeps its code signing CAs though.
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #8 from Matthew Toseland toad@amphibian.dyndns.org --- Created attachment 67758 --> https://bugs.winehq.org/attachment.cgi?id=67758 Launcher log after adding the Verisign CA
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #9 from Matthew Toseland toad@amphibian.dyndns.org --- Created attachment 67759 --> https://bugs.winehq.org/attachment.cgi?id=67759 Wine log after adding the Verisign CA
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #10 from Matthew Toseland toad@amphibian.dyndns.org --- I appreciate that you might see any remaining issues as a different bug. However if you have any further input so I can verify the fix that'd be great.
The remaining problem: - It runs a web server on a random localhost port. - This works, it serves an EXE of some kind. - The client side executable connects to localhost, then closes the connection without doing any I/O AFAICS. The full strace log is 700MB, snippet:
[pid 159812] connect(169, {sa_family=AF_INET, sin_port=htons(44519), sin_addr=inet_addr("127.0.0.1")}, 16 <unfinished ...> ... [pid 159812] <... connect resumed>) = -1 EINPROGRESS (Operation now in progress) ... [pid 159812] close(169 <unfinished ...>
+relay or even +wintrust seem to kill the app completely, so a bit stuck...
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #11 from Matthew Toseland toad@amphibian.dyndns.org --- Created attachment 67761 --> https://bugs.winehq.org/attachment.cgi?id=67761 +wintrust log after fixing the Verisign issue
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #12 from Matthew Toseland toad@amphibian.dyndns.org --- Log attached with +wintrust. There's an obvious error but googling the fault code is completely unhelpful. Looks like another certificate error though.
download.solidconfig has a valid signature according to osslsigncode.
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #13 from Matthew Toseland toad@amphibian.dyndns.org --- Latest testing is on bullseye (Debian 11 prerelease). I may try on Buster on a VM later. Thanks for all your help anyway.
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #14 from Paul Gofman pgofman@codeweavers.com --- Created attachment 67762 --> https://bugs.winehq.org/attachment.cgi?id=67762 Always return success in WinVerifyTrust
(In reply to Matthew Toseland from comment #9)
Created attachment 67759 [details] Wine log after adding the Verisign CA
Yes, the error looks similar. I tested that on Debian 10 though and did not see the error after adding that certificate, but that could be because I copied the game installation which was actually up to date. If it is indeed exactly the same issue with another certificate the attached patch should probably make it work. It is not a fix though, it just effectively disables these sort of verification which is not the right thing to do.
If you see which certificate is there on the executable you can look up the root certificate in it and add it to the system the similar way to the above. Wine does not store those certificates apart from maybe a couple of MS ones, they are read from the host root CA certificate store.
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #15 from Matthew Toseland toad@amphibian.dyndns.org --- Adding the Thawte root CA does not solve the problem. osslsigncode already accepts the signature but maybe it has a separate certificate store; adding the CA *did* change something according to update-ca-certificates.
Is it possible to find out what certificate verification is failing?
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #16 from Matthew Toseland toad@amphibian.dyndns.org --- Your patch works.
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #17 from Matthew Toseland toad@amphibian.dyndns.org --- Created attachment 67764 --> https://bugs.winehq.org/attachment.cgi?id=67764 Output of osslcode verify download.solidconfig
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #18 from Matthew Toseland toad@amphibian.dyndns.org --- Googling the signer ID suggests that the old Verisign Class 3 certs are needed (which are not only officially withdrawn but signed with SHA1, ugh!). However adding them does not fix the problem. I wonder if it could be something else, e.g. timestamping...
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #19 from Matthew Toseland toad@amphibian.dyndns.org --- After much scary unfamiliar hacking, the failure occurs because we get a CERT_TRUST_IS_UNTRUSTED_ROOT on "thawte Primary Root CA".
Which I definitely did add to the global CA store! :(
https://bugs.winehq.org/show_bug.cgi?id=49515
SwampRabbit mx.linux.gamer@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mx.linux.gamer@gmail.com
--- Comment #20 from SwampRabbit mx.linux.gamer@gmail.com --- I can confirm this issue on MX Linux 19.2 (Debian 10) but with Steam Proton 5.0.9.
I was able to get passed the initial error: "ERROR Patch manifest state error in eualas: UnzipFailed (6) (e206)" by adding the VeriSign Class 3 Public Primary Certification Authority - G5
But then I get: "ERROR Download Error :Download configuration failed (e309)"
Users of Manjaro have reported no issues at all, so I believe this is isolated specifically to Debian and the SWTOR client itself.
https://bugs.winehq.org/show_bug.cgi?id=49515
TL HereInPlainSight+wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |HereInPlainSight+wine@gmail | |.com
--- Comment #21 from TL HereInPlainSight+wine@gmail.com --- Juuuust for reference, this is not specifically Debian, this also happens on an up-to-date Gentoo. When I rolled back to a previous ca-certificates package I was able to update and log in. I was hoping they were only necessary during updates, but it looks like they're a part of the update check itself. For the time being, manually added to my ca-certs.
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #22 from Matthew Toseland toad@amphibian.dyndns.org --- @TL which certs did you add? Those removed in some specific version of ca-certificates?
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #23 from TL HereInPlainSight+wine@gmail.com --- After I moved back to the current version of ca-certs, I only added the two mentioned about in this thread. The complete Gentoo answer, which I think would work with any distro but haven't tested, including relevant links, was:
1) Download the first cert listed at https://www.thawte.com/roots/ (direct link is https://www.thawte.com/roots/thawte_Primary_Root_CA.pem ) 2) Copy the cert at https://knowledge.digicert.com/solution/SO5624 into a file. 3) Name both as .crt files. 4) Place both in /usr/local/share/ca-certificates/ (creating if necessary) 5) Ensure they're readable by all users that need them. 6) sudo update-ca-certificates
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #24 from SwampRabbit mx.linux.gamer@gmail.com --- @TL and Matthew Toseland thank you both.
So it seems like a STWOR specific issue then. You'd think that other distros would be updating their ca-certificates packages and reporting it as an issue as well.
I'll give the certs mentioned a go first chance I get.
Thanks again
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #25 from Matthew Toseland toad@amphibian.dyndns.org --- That works for me. Weird, I'm pretty sure I already had the Thawte CA. Thanks!
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #26 from Matthew Toseland toad@amphibian.dyndns.org --- Maybe I'll work on a staging patch to include certificates which are not installed system-wide... although I guess they'll have to change them soon.
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #27 from Matthew Toseland toad@amphibian.dyndns.org --- OpenSSL apps support this. Ideally we'd like Wine to support SSL_CERT_DIR / SSL_CERT_FILE (or --cacert/--capath). Would a patch for this be likely accepted? This is probably a separate bug.
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #28 from Paul Gofman pgofman@codeweavers.com --- (In reply to Matthew Toseland from comment #27)
OpenSSL apps support this. Ideally we'd like Wine to support SSL_CERT_DIR / SSL_CERT_FILE (or --cacert/--capath). Would a patch for this be likely accepted? This is probably a separate bug.
I don't see how that helps, at least alone: CA certs can already be added manually at the host. The main problem is that it might be not trivial to link app misbehaviour with the absence (or presence) of some CA certificate. If that would become an ongoing problem maybe a good solution would be holding some additional CA certs in Wine but again that would help only if the sync with the latest Windows certs is maintained somehow and those certs are auto updated with Wine update.
Maybe we can issue a WARN debug output in WinVerifyTrust() if the check is failing to be able to guess these sorts of problems a bit easier. Yet it can't be ERR or FIXME (and thus won't be visible in default output), and actually WinVerifyTrust is failing routinely in many apps by design, so by far the most of that indications will be false positives if treated as the issue indication.
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #29 from Matthew Toseland toad@amphibian.dyndns.org --- My thought was: - Requiring these certificates is really a bug in the Windows app we are emulating, and maybe in Windows itself. - As a general rule, installing outdated certificates system-wide is a bad idea. - This is the sort of thing that could be usefully put into Lutris or Crossover per-app configuration.
Having said that, the fact that it was so difficult to find out exactly which certificate verification was failing and causing the problem suggests the logging is insufficient even with WINEDEBUG=+wintrust, so I strongly agree with adding some more (helpful) logging. The patch I have locally would need quite a bit of cleanup. I'll attach it anyway.
If Windows always has these certificates then hardcoding them is maybe acceptable for now, maybe dependent on version?
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #30 from Matthew Toseland toad@amphibian.dyndns.org --- Created attachment 67780 --> https://bugs.winehq.org/attachment.cgi?id=67780 Various stupid logging hacks
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #31 from Matthew Toseland toad@amphibian.dyndns.org --- IMHO the current logging is both excessively verbose and unhelpful. We should log the name of the failing certificate verification. The trace of the rest should be enough to tell whether that's actually causing the error.
The attached patch does more than that and certainly isn't mergeable.
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #32 from Matthew Toseland toad@amphibian.dyndns.org --- I'll try to clean it up later today after Real Work.
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #33 from Matthew Toseland toad@amphibian.dyndns.org --- I guess we should log the full ID as well...
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #34 from Paul Gofman pgofman@codeweavers.com --- (In reply to Matthew Toseland from comment #31)
IMHO the current logging is both excessively verbose and unhelpful. We should log the name of the failing certificate verification. The trace of the rest should be enough to tell whether that's actually causing the error.
The attached patch does more than that and certainly isn't mergeable.
Yes, I also think that getting a failing cert name and / or ID from +wintrust log could be very helpful.
Regarding the present bug, maybe it worth opening a support ticket with SWTOR. I guess Windows did not remove those certs yet, but it probably will at some point and at that moment the launcher will stop working on supported Windows 10, so developers might want to deal with that in advance (or quite possible they are already aware and are planning an update).
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #35 from Matthew Toseland toad@amphibian.dyndns.org --- I've added it to my existing support ticket. One of the main purposes of support is to prevent users from filing bugs, but I guess it's possible that they'll pass it on. Hopefully they're aware of it and will fix it when it affects Windows - at some point MS will remove those certificates in an update.
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #36 from Paul Gofman pgofman@codeweavers.com --- FWIW, here is the relevant link on Symantec Root CAs deprecation by MS: https://www.microsoft.com/security/blog/2018/10/04/microsoft-partners-with-d...
It doesn't list - V5 certificate explicitly though, while (as I read it) states that all Symantec Root CAs are to be deprecated.
I found that link through this one: https://bugs.openjdk.java.net/browse/JDK-8207258
which also links other entities' announcements deprecating Symantec CAs, and those mention G5 explicitly.
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #37 from Matthew Toseland toad@amphibian.dyndns.org --- Reported upstream here: http://www.swtor.com/community/showthread.php?t=982395
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #38 from SwampRabbit mx.linux.gamer@gmail.com --- I just want to thank everyone involved with this.
Truly amazing amount of "extra mile" effort put into providing a short term solution, figuring ways to identify such issues in the future, and helping to resolve the root cause of the issue for everyone all around.
I finally got around to installing all the certs listed and sure enough on MX Linux 19.2 (Debian 10) SWTOR on Steam using Proton gets passed the errors and starts downloading and installing everything for the game.
We (MX Linux) have had a user who has wanted to play this game with his son for quite awhile and it looks like he should be able to now thanks to your efforts.
Really great work, keep it up, thanks again!
SwampRabbit (MX Linux Dev Team)
https://bugs.winehq.org/show_bug.cgi?id=49515
bart.massey@gmail.com bart.massey@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bart.massey@gmail.com
--- Comment #39 from bart.massey@gmail.com bart.massey@gmail.com --- Missing certificates issue is still present. Here's current links to the certs you will need to get this working:
https://symantec.tbs-certificats.com/pca3-g5ss.crt
https://www.thawte.com/roots/thawte_Primary_Root_CA.pem
To repeat the previous most excellent instructions:
Rename the second cert from .pem to .crt
Move the certs into /usr/local/share/ca-certificates (will require root privileges).
Run update-ca-certificates as root
You may choose as I did to find launcher.settings in your Wine installation and apply the fix from http://www.swtor.com/community/showthread.php?p=7826333 to turn off Bitraider. (I doubt this is necessary.) The instructions are to replace the last three lines of launcher.settings with these four in the obvious way
, "PatchingMode": "{ "swtor": "SSN"}" , "bitraider_download_complete": { } , "log_levels": "INFO,SSNFO,ERROR" , "bitraider_disable": "true"
Having done these things, my SWTOR is now happily installing under Steam with Proton 5.0. Will comment on playability once I have a chance to try it.
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #40 from bart.massey@gmail.com bart.massey@gmail.com --- Given the cert patching and whatnot, seems to work fine. I had one black-screen hang when leaving the character creator that required killing stuff manually. After restarting, everything seems perfectly normal.
https://bugs.winehq.org/show_bug.cgi?id=49515
Scott Weldon bugs+winehq@scott-weldon.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bugs+winehq@scott-weldon.co | |m
--- Comment #41 from Scott Weldon bugs+winehq@scott-weldon.com --- I ran into this same issue. I have an existing Wine prefix with SWTOR installed, using a pretty old version of Wine Staging on Debian 9, and it was previously working fine, exhibiting no bugs that don't also exist in Windows. But then several weeks ago (didn't record the exact date) I started getting the 206 errors. I tried re-installing to a fresh prefix, but I got the download.solidconfig error mentioned above. The launcher repair tool didn't work either.
(In reply to bart.massey@gmail.com from comment #39)
Missing certificates issue is still present. Here's current links to the certs you will need to get this working:
https://symantec.tbs-certificats.com/pca3-g5ss.crt
https://www.thawte.com/roots/thawte_Primary_Root_CA.pem
To repeat the previous most excellent instructions:
Rename the second cert from .pem to .crt
Move the certs into /usr/local/share/ca-certificates (will require root privileges).
Run update-ca-certificates as root
These instructions worked for me; after doing this, the launcher was able to connect and launch the game successfully.
I agree that some solution to make the source of this error more obvious, such as better logging, would definitely be helpful. After trying a few things unsuccessfully, I had given up and switched back to Windows for playing SWTOR. *shudder* I didn't actually find this bug until recently when I happened to check the AppDB page, and noticed a new bug was listed.
https://bugs.winehq.org/show_bug.cgi?id=49515
Le Gluon du Net legluondunet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |legluondunet@gmail.com
--- Comment #42 from Le Gluon du Net legluondunet@gmail.com --- Hello,
with this workaround:
Here's current links to the certs you will need to get this working: https://symantec.tbs-certificats.com/pca3-g5ss.crt https://www.thawte.com/roots/thawte_Primary_Root_CA.pem Rename the second cert from .pem to .crt Move the certs into /usr/local/share/ca-certificates (will require root privileges). Run update-ca-certificates as root
I can finally install SWTOR on POP OS 20.10.
But I don't understand why I need it on some Linux distribution and not on others?
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #43 from Le Gluon du Net legluondunet@gmail.com --- POP OS 20.10: needs to install manually certificates Ubuntu 20.04 and Arch: don't need.
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #44 from Le Gluon du Net legluondunet@gmail.com --- similar issue for Elder Scroll Online on some Linux distributions, the game stuck at "install" step or will not update until you manually install this three certificates: wget https://www.thawte.com/roots/thawte_Primary_Root_CA.pem wget https://www.thawte.com/roots/thawte_Primary_Root_CA-G3_SHA256.pem wget https://www.thawte.com/roots/thawte_Primary_Root_CA-G4_DSA.pem
https://bugs.winehq.org/show_bug.cgi?id=49515
Fernando Tonon de Rossi tonon.fernando@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tonon.fernando@hotmail.com
--- Comment #45 from Fernando Tonon de Rossi tonon.fernando@hotmail.com --- (In reply to Le Gluon du Net from comment #43)
POP OS 20.10: needs to install manually certificates Ubuntu 20.04 and Arch: don't need.
I'm using Ubuntu 20.04 and manually installing the certificates solved the problem, thank u all!
https://bugs.winehq.org/show_bug.cgi?id=49515
Alex alexzk@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexzk@mail.ru
--- Comment #46 from Alex alexzk@mail.ru --- Today swtor stopped to work on arch. Used crt from here to fix, thanks. How to on arch: https://wiki.archlinux.org/index.php/User:Grawity/Adding_a_trusted_CA_certif...
https://bugs.winehq.org/show_bug.cgi?id=49515
Ian Cole imcole@pm.me changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |imcole@pm.me
--- Comment #47 from Ian Cole imcole@pm.me --- Created attachment 69651 --> https://bugs.winehq.org/attachment.cgi?id=69651 osslsigncode timestamp error
Thanks so much for the investigation in to this. I tried adding all of the certificates listed here but I still seem to be getting an error. My osslsigncode seems to be complaining about the certificate timestamp. Is there any way to work around this?
https://bugs.winehq.org/show_bug.cgi?id=49515
--- Comment #48 from Ian Cole imcole@pm.me --- (In reply to Ian Cole from comment #47)
Created attachment 69651 [details] osslsigncode timestamp error
Thanks so much for the investigation in to this. I tried adding all of the certificates listed here but I still seem to be getting an error. My osslsigncode seems to be complaining about the certificate timestamp. Is there any way to work around this?
Sorry to resurrect this old thread. You all just just ignore me. Turns out my issue was because I was running Steam as a Flatpak and not a native client, so even though my certificates were imported they weren't being recognized by the contained Flatpack environment. Perhaps that will help someone else applying this fix in the future. Will have to think twice about using Flatpaks now.
https://bugs.winehq.org/show_bug.cgi?id=49515
markovswtorpass@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |markovswtorpass@gmail.com
--- Comment #49 from markovswtorpass@gmail.com --- On Fedora 35 i copied the 2 certificates to /usr/share/pki/ca-trust-source/anchors/
then ran sudo update-ca-trust
that fixed the issue of the launcher stuck on updating.
https://bugs.winehq.org/show_bug.cgi?id=49515
rawfox rawfox@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rawfox@freenet.de
--- Comment #50 from rawfox rawfox@freenet.de --- jup, that does the job, thanks a ton ^^
http://bugs.winehq.org/show_bug.cgi?id=49515
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTOURBUG
--- Comment #51 from Ken Sharp imwellcushtymelike@gmail.com --- Certificates are maintained by distros, not Wine.
-
WineHQ Bugzilla