You can sign up to get a daily email of our articles, see the Mailing List page!
Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through Paypal, Flattr and Liberapay.!
Latest Comments by marcus
According to Kotaku, Microsoft is close to buying Obsidian
11 October 2018 at 7:21 am UTC

Purple Library GuyMind you, I have to admit there's something fitting about Microsoft owning Tyranny.

Luckily, like shmerl wrote, they don't own Tyranny. The IP is owned by Paradox.
Sadly that might also mean we won't get another Tyranny game anyways, since it did not seem to much of a commercial success making Paradox reluctant to invest into the IP.

Some thoughts on State of Mind from Daedalic Entertainment
15 September 2018 at 8:24 pm UTC Likes: 8

This might be getting off-topic here, but I want to chime in and voice my support for rolling credits. I just love them. I always watch them to the end, both in cinemas and in games. Besides being a nod of respect to the developers I like to take the time to reminisce about the plot or ending, especially if it was climatic. A nice credit roll, together with music fitting to the game/movie is something I thoroughly enjoy. Of course I understand that not everybody likes this and they should a) be skipable and b) scrollable (in an extra format from the menu). But I really want them to auto-roll and do so as the artists intended at the end of the movie/game.

I find it kind of sad that Netflix defaults to showing the main credits minimized and you have to refocus them to watch them. It takes one out of the mood and breaks the experience. I would much prefer if they made that optional.

Reminder: Update your PC info for the next round of statistics updates
29 August 2018 at 8:06 pm UTC Likes: 1

Wine/Proton: I would advocate for two questions. This would mirror the fact, that a wine play will get registered as Windows play for the dev, while a Proton play would count towards Linux usage. This is important (at least for me) for how often I am willing to use Wine/Proton.

The AMD/Nvidia graph: I just noticed ... the colors are different for the same answers (open/closed) in the AMD and Nvidia graphs. Could you fix that Liam so that same answers get same colors? This would make visual comparison easier.

Snap! The new Minecraft launcher now has another easy way to be installed on Linux
25 July 2018 at 8:32 pm UTC

TheSHEEEP
marcus
TheSHEEEPSo what if ffmpeg, the standalone executable, has a security leak in a very weird circumstance? The only thing I do in my application is using it for a very specific use case that is fully under my control.
What about a multiplayer game that uses avatars? This is not under your control. I can inject an infected jpeg that exploits the library there.
And that infected jpg will not get you anywhere, as neither the server you upload to nor the users that will see it later will ever "execute" the .jpg file on their computers.
There is a reason no game allows its players to just upload any file, and if a file is uploaded, it is at the very least converted or checked. Because if that isn't done, that would indeed be an exploit. But not one that would have been prevented by updating a library.

I think you lack some basic knowledge here on how exploits for media formats work. They are usually completely valid or at least seemingly valid files that trigger internal buffer overflows in the processing libraries. An infected jpeg ist not an executable. It triggers code paths in the library responsible for rendering the jpeg and this *will* be done on your machine.

TheSHEEEP
marcusThis is not a myth. A number of recognized publications analyzed exactly this problem of the vulnerabilities introduced by bundled libraries. The this one from the reputable OAKLAND security conference as an example: http://legacydirs.umiacs.umd.edu/~tdumitra/papers/OAKLAND-2015.pdf
That paper brings examples that completely defeat the point:
QuoteThe user is running two versions of Adobe Reader, a default up-todate version and a vulnerable version. The attacker convinces the user to install a Firefox add-on that looks benign. The malicious add-on has filesystem access through the XPCOM API [4]. It locates the vulnerable and patched versions of the Adobe Reader library (nppdf32.dll) and overwrites the patched version with the vulnerable one.
Note the bold part.

You concentrate on a point of the paper that was not even subject of the discussion here. Look into section IIA and concretely all the discussion around deployment delay. This is exactly the problem bundled libraries invite.
The inactive program versions part of the paper was not subject of this discussion here. This is only relevant to circumvent auto patching techniques of bundled libraries. These are clearly not in effect here (for steam games or SNAPs / Flatpacks)

TheSHEEEPNobody, ever, has been or will be hacked or in any way influenced by a game not using the most recent version of OpenSSL. Otherwise, these games would have updated their dependencies, been removed from Steam, made it to the news, etc..
This isn't true for every kind of program or application, obviously. Especially programs that are themselves important parts of operating systems are better served by automatically using the latest version.
But a game and many other kinds of "non-system" software certainly doesn't belong to that category.

Sorry, but this is just reckless and shows that you put a completely different weight on security than I do. I don't say that I wouldn't use games due to this, but denying the risks and making such sweeping statements as you do ("Nobody, ever, has been or will be hacked [...]" ) ist just reckless.

TheSHEEEP
marcusLets agree to disagree here: You value "It just works" more than "it is secure" and I do the other way around. It's just a matter of different priorities.
I do value my security.
I just also realize that my security isn't in the least reduced by my games coming packaged with their own dependencies. Because there is no realistic way to abuse those dynamic libs lying in some /lib folder of my installed game if I don't go ahead and install shady software from untrusted sources.
What I don't do is put on a tinfoil hat, fearing and preparing for theoretically possible attacks that never did and never will happen to me.

See above. Call me all the funny things you like, but denying that there are risks and that they are real is dangerous. You abuse those vulns by just sending packets to the port of your game server that trigger them (OpenSSL vulns), hand crafting user-provided images (libjpeg) or hand crafting user-provided strings like names (ui-rendering vulns).

Snap! The new Minecraft launcher now has another easy way to be installed on Linux
25 July 2018 at 6:14 am UTC

TheSHEEEP
marcus
TheSHEEEPBut what is the argument?

It saves space? In a time when space is disk virtually free (except for SSDs, disks are basically giveaways), this is a non-issue.
It obviously works for Windows, and binaries on Windows can be strangely large.
It does obviously not work under Windows. On Windows every application ships its special funny version of ffmpeg or libjpeg for example. Do you think this ever gets updated to fix bugs? I think adapting the Windows approach (and in the end all these snaps, flatpacks, docker images (lets subsume them under "containers") and whatnots are nothing else + a bit more isolation) is a bad thing. It encourages packaging libraries and then abandoning them because "the application works".
"The application works" is the one and only important criterium.

No. This might be the case for you, but others care about the security of their system as well. I'd prefer if an application does not expose a vulnerability silently. If it suddenly stops working with my system libjpeg then I'll notice. I will not notice if it just bundles its own broken libjpeg.

TheSHEEEPSo what if some dependent library gets an update? If the update is important for your application, you can just update it to the recent version.
If the update isn't important to your application (which is the vast majority of cases), you don't need to do anything.
How do I update a library in a SNAP/FLATPAK/docker container manually? How do i keep track of all the different installed versions of a library in different applications? This *is* exactly the job of the system package manager. This is (at least for me) one of the key advantages of Linux - centrally managed libraries and applications that are monitored for vulnerabilities by maintainers.

TheSHEEEP
marcusIn a distro, a library that has a vulnerability gets either updated or (lacking updates) removed. Sure this breaks you application if ABI breaks or if there is no fixed version, but for good reason! It removes a vulnerability from your system.
But we're not talking about distros here, we're talking about distributing applications. For the OS itself I actually think this variant of relying on external packages makes sense. But not for single applications that do not even want to become part of the system (like games).
So what if ffmpeg, the standalone executable, has a security leak in a very weird circumstance? The only thing I do in my application is using it for a very specific use case that is fully under my control.

And this is the dangerous misconception. What about a multiplayer game that uses avatars? This is not under your control. I can inject an infected jpeg that exploits the library there. Same goes for networking libraries. openssl for example, which a lot of applications depend on directly exposes all network based communication to exploitation if it has a bug that is not fixed.

TheSHEEEP
marcusThey suggest that breaking APIs and ABIs is fine. You can just package the right version and the library dev can then go on developing without having to backport fixes to the old code.
Breaking APIs and ABIs IS FINE. You can take a look at Windows API programming prior to Windows 8 to see the absurd legacy shit Windows devs had to deal with because Microsoft was afraid to break APIs.

And the second sentence is exactly the point - it is less work for everyone involved without any downside. Plus the library dev still has to backport if too many users of the library for some reason cannot switch to a newer version.

No. It is not. The downside is a security vulnerability shipped with your application. You may not care about this, but others, like me, do.

And breaking ABIs and APIs *is* fine if you use semantic versioning. And best if you also maintain security fixes for the old ABI/API version for at least some time to give the downstream a chance to update. Especially in the "agile" world today this seems often no longer the case.

TheSHEEEP
marcusThis is a huge problem and going that route will invite many of the security holes we find in the Windows world into the Linux world.
This is mostly hearsay without any basis. The reasons linux has less breaches than Windows is first and foremost that it is a smaller target - if it ever becomes big, that will change in an instant - and the second part is that no application can just go and change system files, run cronjobs, etc. without the user's approval.
The "annoying" thing of having to type your password each time is actually way more secure than Windows' popup where you have to click a button.
This is not a myth. A number of recognized publications analyzed exactly this problem of the vulnerabilities introduced by bundled libraries. The this one from the reputable OAKLAND security conference as an example: http://legacydirs.umiacs.umd.edu/~tdumitra/papers/OAKLAND-2015.pdf

I do not dispute that there are other mechanisms that make Linux more secure (though the password vs. click a button thing is not one of them -- as a sysadmin I see way to many people that mindlessly type sudo and enter their password). And sure, you do not immediately get root access, but neither do you get that on windows usually. But having local execution capabilities is an important first step for any attack and should not be invited by having old, unmaintained code --- no matter in which application.

Here some examples from some of the games shipped by steam that I have installed:
ShadowOfMordor, Alien Isolation, Life is Strange, Borderlands 2 --- OpenSSL 1.0.1 14 Mar 2012
Expeditions: Conquistador, Element4L, TIS-100,Oxenfree --- OpenSSL 0.9.8o (32 bit) and 1.0.0g (64 bit)
Pillars Of Eternity --- OpenSSL 1.0.0g
Talos Principle --- OpenSSL 1.0.1i (Last patch release of 1.0.1 was 'u')
Millie The Centipede --- OpenSSL 0.9.8o

OpenSSL 1.0.1 is unmaintained and does not receive fixes. The last release was made roughly 2 years ago ... 1.0.0 is even older and unmaintained longer, so is 0.9.8 ....

These games use the network (at least Borderlands 2 does). Same goes for the steam API here btw. They should really provide security updates for it ... No sane distribution still ships OpenSSL 1.0.1. They all moved on to 1.0.2. Steam itself uses 1.0.2j btw. We are at 'o' as the current patch release --- which is also installed by my distro.

TheSHEEEPAnd lastly, Linux distros are developed differently, with a lot more different eyes on the code. Leaks are more easily found and fixed this way. Open source development is, in the end, more secure.

Actually, this is a fallacy that has been often debunked and does not even help, if the updates that are enabled by this are then not installed because applications ship old library version.

TheSHEEEP
marcusIf you want to do this, be at least honest: statically link the libraries in. Because in the end, all those funny container formats are doing the same.... just not using static linking. Containers are already there. They are called static binaries. No dependency hell required.
This is terrible advice and shows that you have zero experience developing software for end users.
First of all, some software you cannot even link statically without breaching license (FFmpeg, for example, forces you to give away object files of your project, or go open source yourself - check this).
Also, software (usually) needs updating. That usually means your own code has changed, and sometimes it means a dependency has updated and you wanted that change.
If you link all your dependencies statically, each and every update will be - depending on the size of your dependencies - gigantic. While space is virtually unlimited, bandwidth unfortunately still isn't. And this propagates - from your repo (if you got binaries there, maybe in a git LFS) to the build server, to the install build server (if separate) to the CDN to every user. Trust me, that is a big no-no.

The only benefit of static linking is that people won't know what libraries you use (if for some reason you want to hide that???) - so it is actually less honest than dynamic linking.

But securitywise it's the same (You are right with the license issue though. I forgot about that. Btw: I don't link statically, but I also don't ship my dependencies myself ...). Btw: Many steam games statically link OpenSSL (all of the above listed that are not from Feral, if my script worked correctly).

Lets agree to disagree here: You value "It just works" more than "it is secure" and I do the other way around. It's just a matter of different priorities.

Snap! The new Minecraft launcher now has another easy way to be installed on Linux
24 July 2018 at 8:31 pm UTC Likes: 1

TheSHEEEPBut what is the argument?

It saves space? In a time when space is disk virtually free (except for SSDs, disks are basically giveaways), this is a non-issue.
It obviously works for Windows, and binaries on Windows can be strangely large.

Security. I'm with Exidan on this, but from a slightly different angle.

It does obviously not work under Windows. On Windows every application ships its special funny version of ffmpeg or libjpeg for example. Do you think this ever gets updated to fix bugs? I think adapting the Windows approach (and in the end all these snaps, flatpacks, docker images (lets subsume them under "containers") and whatnots are nothing else + a bit more isolation) is a bad thing. It encourages packaging libraries and then abandoning them because "the application works".

In a distro, a library that has a vulnerability gets either updated or (lacking updates) removed. Sure this breaks you application if ABI breaks or if there is no fixed version, but for good reason! It removes a vulnerability from your system.

Use an upstream supported library version in your application and you are fine. Admittedly there are libraries that have never heard of stable APIs/ABIs or semantic versioning, but that's a problem on its own and those container formats are not a solution to them but part of the problem. They suggest that breaking APIs and ABIs is fine. You can just package the right version and the library dev can then go on developing without having to backport fixes to the old code.

This is a huge problem and going that route will invite many of the security holes we find in the Windows world into the Linux world. If you want to do this, be at least honest: statically link the libraries in. Because in the end, all those funny container formats are doing the same.... just not using static linking. Containers are already there. They are called static binaries. No dependency hell required.

Thoughts on the Corsair STRAFE RGB Mechanical Keyboard with Cherry MX Silent Switches
24 July 2018 at 8:15 pm UTC Likes: 1

For desktop use (and programming) I can very much recommend Das Keyboard. I have a Das Keyboard 4 Pro with Cherry MX Blue switches and it is really great. I never want to use anything else again. I ponder getting one with brown or similar switches for work (since co-workers might be annoyed by the loud click of the blue switches).

I also got the very important Tux Keycaps for the Super Keys: https://shop.daskeyboard.com/collections/accessories/products/linux-key-cap-bundle-1

The only thing I really miss and would like to have is a keyboard with ISO layout and english keycaps. They all only sell the ANSI layout which I find harder to use. I like the big enter key I can just smash down on

See the difference here: https://deskthority.net/wiki/ANSI_vs_ISO

Zachtronics' next puzzle game 'EXAPUNKS' will have you writing viruses, announced with Linux support
21 July 2018 at 7:59 pm UTC Likes: 1

Thank you so much for covering this! This time I won't miss out on the special edition like I did with TIS and SHENZEN I/O.

Paradox Interactive now owns 100% of developer Harebrained Schemes
7 June 2018 at 7:19 am UTC

Schattenspiegelbut they also deeply into this telemetry and required user accounts crap

Can you qualify that? IMHO the "required user accounts crap" is wrong. I own CK2, EU4, Tyranny, PoE and none of these games forces me to have an account. If I have one I can sign in, but I was never forced. IIRC one of the games asked me if I wanted to provide telemetry data, and I assume that when I rejected this rejection was honored. So is this statement of yours based on facts or just hearsay?

2nd generation AMD Ryzen desktop processors now available to pre-order
13 April 2018 at 7:40 pm UTC Likes: 3

Cestus<<--- party pooper Anyone know the status of meltdown v1 V2 and spectre? is it fixed to the hardware level with these new CPU?

AMD was not affected by V3/meltdown.
V1/Spectre is mitigated in the OS (RETPOLINE)
V2/Spectre is hard to exploit on AMD and fixed in microcode (https://www.amd.com/en/corporate/security-updates)

  Go to:
Livestreams & Videos
Community Livestreams
  • MMOre Fun: „Guild Wars 2“ (via Wine)
  • Date:
See more!
Popular this week
View by Category
Contact
Latest Comments
Latest Forum Posts