I personally don’t think they do, but an argument can certainly be made. Rust proc macros can run arbitrary code at compile time. Build scripts can also do this.
This means, adding a dependency in Cargo.toml is often enough for that dependency to run arbitrary code (as rust-analyzer will likely immediately compile it).
In practice, I don’t think this is much worse than a dependency being able to run arbitrary code at runtime, but some people clearly do.
I don’t know if it is a huge issue but it is definitely a nice to have. There are a few examples I can think of:
I open the code in my IDE but build somewhere sandboxed. It would be nice if my IDE didn’t execute the code and can still do complete analysis of the project. This could also be relevant when reviewing code. Often for big changes I will pull it locally so that I can use my IDE navigation to browse it. But I don’t want to run the change until I finish my review as there may be something dangerous there.
I am working on a WebAssembly project. The code will never run on my host machine, only in a browser sandbox.
I want to do analysis on Rust projects like linting, binary size analysis. I don’t want to actually run the code and want it to be secure.
I want to offer a remote builder service.
I’m sure there are more. For me personally it isn’t a huge priority or concern but I would definitely appreciate it. If people are surprised that building a project can compromise their machine than they will likely build things assuming that it won’t. Sure, in an ideal world everyone would do their research but in general the safer things are the better.
Analyzing without running might lead to bad situations, in which code behaves differently on runtime vs what the compiler / rust-analyzer might expect.
Imagine a malicious dependency. You add the thing with cargo, and the rust analyzer picks it up. The malicious code was carefully crafted to stay undetected, especially in static code analysis. The rust analyzer would think that the code does different things than it actually will. Could potentially lead to problematic behavior, idk.
Not sure how realistic that scenario is, or how exploitable.
I don’t think this is a problem with proc macros or package managers. This is just a regular supply chain attack, no?
The way I understand it, sandboxing would be detrimental to code performance. Imagine coding a messaging system with a serve struct, only for serde code to be much slower due to sandboxing. For release version it could be suggested to disable sandboxingy but then we would have gained practically nothing.
In security terms, being prepared for incidents is most often better than trying to prevent them. I think this applies here too, and cargo helps here. It can automatically update your packages, which can be used to patch attacks like this out.
If you think I’m wrong, please don’t hesitate to tell me!
You almost have to go out of your way to make a game incompatible with linux. Considering wine/proton and their various forks cover the vast majority of things at this point.
Even with ACs, the two most used ones completely support Linux. One is completely out of the box, maybe even as far as linux support being opt out. The other requires you to contact its developers to enable compatibility their end iirc.
I don’t agree. There are cases with Windows only root kits for DRM, but there are also games that don’t work because of bugs. You see games coming out that barely work on Windows.
Yeah, there’s this very obscure match-3 game I wanted to play because of nostalgia. The series peaked with 3 and 4 (and those are the ones we played on the family computer circa 2015) and worked perfectly on Windows. Now 3 works perfectly (in terms of compatibility) but 4 was better (in terms of gameplay). 4 is marked as borked, last I checked. For anyone wondering, it’s The Treasures of Montezuma series.
I mean, it is not a fault on Linux’s end. We have all the tools we need in the form of wine and dxvk, it’s the game which fails to work due to some obscure dependency or a mandatory rootkit. One great example is genshin- the game itself works flawlessly, but it has a rootkit which obviously does not work on Linux and you have to patch it out.
Yeah, similar to windows warning you that your network share won’t be available when you’re computer is off or in sleep mode, it’s stupid for me as an IT person but on the other hand as an IT person I know users can be stupid and such warnings are needed
I blame Linux distros for being too complicated and unintuitive for 95% of the population, which in turn gives it a negligible market share from a game development perspective.
seriously though the installation experience on kde/gnome is so much nicer than windows, if the hardware is compatible and the tpm/secure boot bullshit is turned off
When I had to learn Novell NetWare the textbook we received was just as bad and the instructor didn’t have a clue either. Because internet wasn’t exactly widely available for information like this then, we wrote a DOS batch file that discarded our input and miniced the output of the client for the practical exam. We all passed.
To be fair, game programming is very often hot garbage. Most things I run do not respond for a while at startup. How difficult can it be to decouple your threads?
I’ve recently started gaming on linux with surprisingly little problem, given that the last time I tried was about 15 years ago. I don’t even know what proton is, but I just installed steam and then my games… surprisingly on some slightly older games (tf2, HL2) I get a huge FPS boost in Linux compared to windows. Not sure why that would be.
surprisingly on some slightly older games (tf2, HL2) I get a huge FPS boost in Linux compared to windows
Oh, I remember watching video on youtube on that topic. Short answer: because opensource. Long answer: because developers better understood how to optimize. Same optimizations slightly boosted FPS on windows.
I don’t even know what proton is
Valve games run natively on Linux, so no need in proton.
Proton is basically Wine bundled with other software, like DXVK and VKD3D, to run windows games.
You have to enable it in the Configuration window inside of Steam if you haven’t done that yet. Enabling it is all you have to do and it will be used automatically.
Ah thanks, I don’t think I have enabled it. Will that allow me to try out windows-only games in Linux? That’s crazy… literally no more reasons to go back to Windows…
Yep. You can have a look at ProtonDB to have an ideia of how well a game runs through Proton.
It’s not completely correct as some games marked with lower ratings will work flawlessly, and some with higher ratings will probably give you some trouble, but it’s a really useful resource.
lemmy.ml
Active