New launcher... new Linux error?

EVE Technology and Research Center Linux
103

Indeed, when I made the permanent switch to Linux it was because I felt we at least had some kind of backing in CCP, albeit unofficially. I was also fully aware that it’d be some hardship here and there, but mostly that it’d work.

My issue here is that it isn’t the game that is causing upsets for compatibility, it’s the f… launcher. Although I do appreciate @CCP_Cemetery taking his time to comment, we’re lacking good c o m m u n i c a t i o n.

Mind you I’m also perfectly aboard changes that improve security and do understand the premise of token theft and support enhancements to prevent, but c’mon how hard could it have been to just add a -legacy_token_storage argument to the launcher, which does not use the new and improved storage? Or -no_auto_update so we can have some grace-time to resolve situations like these?

We are okay with us being non-supported (we’ll make it work anyhow), just don’t actively try to break it without at least being somewhat transparent.

For me personally, using Wine 5.0/no DXVK is not an option as I’ve worked quite a bit to get a good setup which doesn’t impact performance, as I multibox (up to 4-5 accounts) and manually pilot. Every single day. Bad performance means I might feed expensive ships or not being able to support other pilots sufficiently on-grid.

4 Likes
104

Hey all, CCP Bartender here!

There’s been a little bit of confusion about what’s happening with EVE and Linux. Let me do a little information dump and clarify some things.

Before we get to that, I want to reiterate that CCP discontinued official support for Linux in early 2009. A combination of some convenient early technical decisions and extra time by Linux-using devs has allowed Linux to remain surprisingly viable for the last decade, but it is not a supported operating system.

A forum post mentioned that the change yesterday would break how the launcher works on Linux. Our current business focus is on Windows and macOS. The change implemented is based on moving from storing tokens in our own home-rolled token storage mechanism to using secure credential storage on the OS itself. This is a significant boon to account security, and the safety of the accounts of our Windows and macOS users is simply a much higher priority than the ability to run on unsupported operating systems.

With that in mind, let’s talk about whether the EVE launcher works on Linux right this second. Because it is not a supported OS, we do not do QA on Linux machines. Occasionally, some ad-hoc testing on personal Linux machines, including my own, takes place, and the last time we did it, both the native and proton environments failed to launch clients.

Since that testing occurred, some fallbacks for credential handling have been implemented to allow for a more robust transition to OS credential storage while reducing the risk of mass-logout problems. By a happy chance, this means logins are still working under proton, which can run the Windows version of the launcher and has an up-to-date QT application binary. However, it is not working under the native launcher, which has not been updated for around a year, due to certain new dependencies that do not support Linux preventing compilation and thus has an outdated QT binary running the latest webUI.

Those using the native launcher should consider this the end of the road for that avenue of playing EVE under Linux. With the upcoming native port of the macOS client to Metal, once our Mac client does not require wine, that infrastructure will inevitably be torn down.

Fortunately for all Linux gamers, Valve has been doing a fantastic job with proton over the last few years, and at this time, you can use proton to play EVE (I certainly will be!). Key details of my currently functional setup are as follows:

  • Ubuntu 18.04
  • Proton 5.0-10
  • i7-4770-k
  • Nvidia RTX 1060
  • Kernel 4.15.0-147-generic

I hope this can act as a guide to help others who might be having issues get up and running again for now.

Let’s talk about the future, though. At some point, the transitionary code for the credential storage will be removed. When that happens, it is expected (but untested) that the same issue seen in the native launcher will express in the proton launcher too. There is some internal discussion about this, but at this time, Linux users should be aware that unless wine or proton adds support for the syscalls involved in the windows credential store, proton will eventually stop working too. The exact timeline for this is amorphous, and it is impossible to say whether that’s one month or twelve months. We might see support for the credential store land in upstream wine before that happens, but the matter is very much outside our scope for day-to-day work.

I hope it brings clarity to the discussion. Stay awesome, my fellow Linux nerds! o7

17 Likes
105

But don’t you think it’s a bit sad that the actual game would run perfectly well on Linux without any effort from you, and once again the part that breaks it is the f-ing launcher?

6 Likes
106

Are there any plans to make a native version of the launcher and/or client?

With the work towards making it work with Mac, I imagine it’d at least be closer to possible, since there’s many similarities there. Main thing would be a Vulkan renderer instead of Metal, although if you use MoltenVK, you can get both with some caveats.

For that thread about the old launcher, you may want to add a note that running the game on Linux through proton/wine will eventually fail with an explanation, so that people don’t get too invested.

I’ve been playing Eve with wine and then proton for many years and it’s worked great, but it looks like this is the end of road for that once this legacy mode is removed. My subscription expired at a good time I suppose. I do appreciate the work that was taken to make it work in the past, and would enjoy playing again if this ends up being improved (either by the community or CCP).

2 Likes
107

Thank you very much for the detailed explanation! This should be helpful for setting expectations and figuring out how to move forward on the Wine side of things.

108

It’s not just CCP that has this issue. This is a trend in the gaming industry with all these companies for whatever reason needing to have a “launcher”. Several games have the same problem in common: the game itself works fine in Linux but the part blocking the game from being played is some odd crap in the launcher that prevents it from working.

3 Likes
109

The launcher uses Qt5 with Chromium Embedded Framework (CEF) from what I can tell, so it relies on Chromium to do the rendering. Qt5 tends to use newer platform features if it can; and hence tends to be on the leading edge of issues with Wine where it lacks support for some of Window’s newer features. Just check the number of Wine bugs for Qt5 Window programs. I suspect that because Qt5 has good support on Linux that not much effort is put into support for Qt5 on Windows on Wine on Linux.

Given the number of layers I suspect that supporting a native launcher with Qt5 (with CEF) directly on Linux would probably be less of a support hassle than supporting Qt5 on Windows on Wine on Linux.

But then the economics of supporting a small user base on a different platform (and probably a dose of fear and lothing of the unknown by devs) means they won’t support it. But it would be nice if they gave us a heads up or even just talked to us nicely rather than mustering up tautological circluar arguments (we don’t support it because it isn’t supported) served up with all the tact worthy of a dev.

110

The change implemented is based on moving from storing tokens in our own home-rolled token storage mechanism to using secure credential storage on the OS itself.

Can you confirm if you’re talking about using GitHub - frankosterfeld/qtkeychain: Platform-independent Qt API for storing passwords securely. for storing credentials using the windows credential manager? That would help us focus on the functionality that is currently missing that needs to be supported.

2 Likes
111

If made right It could easily be recompiled to run on Linux, but from the comments above it looks like there is Windows platform specific code in there as well which is preventing that.

112

As far as the Qt5 Library is concerned QtKeychain works natively on Linux just fine (millions use it on Linux and probably don’t realise). But I suspect given @CCP_Bartender 's comments that dependency hell is killing the Linux build process; both Qt5 and CEF (even more so) have a large number of dependencies.

113

I do not want to trust Microsoft to store my passwords in plain text using their Windows Credential Manager. I wonder if this is a move to implement a more secure password storage or to relay to a more vulnerable system to malware attacks. Maybe corporations do a pretty good job to protect our privacy…

1 Like
114

This is one of the most disappointing posts I’ve read from CCP in a while. Just among my personal contacts, I can account for at least 100 Omega accounts depending on this fragile and regularly broken Linux ‘support’.

I never figured that it’d die off because of a tiny detail in the launcher. You could at least publish a list of syscalls which need to be supported in wine but aren’t, if you aren’t going to put in the effort to implement them yourselves.

You’re either completely oblivious to the fact that the current PTU figures make the Blackout era look like a Golden Age, or you don’t understand just how precarious the situation is. MMOs are incredibly sensitive to changes in population. Perhaps instead of thinking about which player bases you can cut loose, you should be thinking about how to avoid terminal decline.

8 Likes
115

For reference, WineHQ Bugzilla – Bug 51465 – EVE Online Launcher Crashes Due to Missing syscalls in Windows Credential Manager is the bug report upstream to Wine.

4 Likes
116

Do you realize that the launcher I linked earlier in this thread works and launches EVE just fine?

117

Yeah, as per the post I replied to it works for now.

118

Sigh…

Well at least thanks for the explanation, but I’m afraid it’s one launcher problem to much for me. Just cancelled my subscriptions.

Good luck and fly safe.

119

Is the secret still passed as a command argument to the client (exefile.exe)?

Even on Windows, command-line arguments are NOT a secure way to pass secrets. If I have an evil process running on your system with your privileges, that process can just ask Windows to tell me what the command-line arguments were.

They’re not secure on Linux for the same root reason: they were never secure on Unix systems. The correct way (Unix/Linux) to pass a secret is by using a file, a pipe, or an environment variable. And while I’m not very familiar with Windows, this answer mentions in passing that Access will not accept a password on the command line, presumably for exactly this reason.

In short, the only way that CCP could have actually improved security in this respect is by changing how the client works, not just some Qt-related stuff in the launcher. I can’t confirm this fact because I haven’t upgraded, but if you’re on Windows, you can:

Look at the command line in Task Manager while you have the client signed in. Mine on Linux (not upgraded) looks like:

C:\EVE\SharedCache\tq\bin64\exefile.exe /noconsole /server:tranquility /triPlatform=dx9 /ssoToken=…

(For your own security DO NOT copy-post the token anywhere.)

Also, I’m not a particularly skilled security researcher. I just ran top on a hunch and noticed “hey, that looks random.”

Note: if I can run an evil process on someone’s machine, I can keylog, I can probably steal their cookies, evesdrop on comms, trick them into resetting passwords, etc, etc. If I don’t have that intimate access, then there was nothing wrong with the old mechanism. It would be kind to allow those of us who know what we’re doing to opt-out of the new mechanism.

Especially if it’s not actually any more secure than the old.

Edit: the Eve client still has a screen that asks for your username and password, the old old method. It will then tell you that method is no longer permitted. The only reason why Eve is (insecurely) passing the SSO token by command line in the first place is that someone decided to make the launcher mandatory!

5 Likes
120

I bet what is really going on has less to do with security and more to do with saving dev time. By using the OS credential store and not using whatever “home-rolled” solution they have been using, likely they can not spend on dev time maintaining the “home-rolled” solution. They can now leave that up to M$ and Apple. If extra security supposedly comes out of it then that is a bonus and a great excuse to tell the player base why they made the decision. Maybe the savings on dev time is worth more than the sum of omega subs from Linux users (I doubt it but who knows?).

Yup! But it has to do with skill injectors, skins, and microtransactions. If they let you log in the old way, then the token is not there to let you buy crap in the New Eden Store and use skill injectors. This is the real reason for the launcher.

1 Like
121

Oh you just sound like you do not realize that. After all it broke at least 2 times past year and the easiest solution (at least for me) was to use previous launcher version. Both times issue was fixed on the Wine side. Crying to CCP about Wine being unable to handle non-invasive windows software is not a constructive approach imo. CCP after all did not add any changes which break wine compatibility for good (i.e. need to run some ring0 level anticheat), they are using higher level system APIs which wine seems to miss.

Yeah because they are absolutely unable to put ads to the ingame login screen or what?

For me as an end user, the biggest advantage of launcher is auto-patching all the clients (tq, sisi) and managing cross-account stuff (settings, authorization, launching multiple accounts at the same time).

1 Like
122

This time Linux users have been hit hard! I hope WineHQ or Valve implement this credential store crap.
Hopefully, “Cancel launcher update” trick will work some time … time to gather my stash in Jita.