As we have previously reported here, optimus-manager, the GPU manager for laptop setups was going silent because the main developer didn't have the time or resources to keep that project running on Github. Looks like it's coming back!
After I got notified that a long-standing bug I'm participating in related to PCI ID generation missing the Domain ID on Xorg configuration generation was closed as fixed, I've noticed that a bunch of other stale Pull Requests got merged recently too.
Referring back to the main discussion thread, "The state of optimus-manager", to my surprise someone nicknamed es20490446e is doing all the hard work to get the software active again and asking people to deliberately tag him on pull requests so he can better handle them because he is not (yet) the owner of the software.
It's nice to have such piece of software back into active state. I've switched back to envycontrol recently because of optimus-manager being abandoned and crashing a lot on newer kernels but, since this software is more feature rich and also supports some of my VFIO (GPU pass-through) stuff, I would definitively give it a try again when it gets in a better shape again.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
9 comments
Don't want to spoil the fun here. But this situation is rather similar to the xz vulnerability. Original dev overworked, other one jumps in. Makes all kinds of changes. Who is es20490446e? Does the software need root access? Ring zero? Nuclear launch keys? 🤔
...I may be overthinking this.
...I may be overthinking this.
5 Likes, Who?
Don't want to spoil the fun here. But this situation is rather similar to the xz vulnerability. Original dev overworked, other one jumps in. Makes all kinds of changes. Who is es20490446e? Does the software need root access? Ring zero? Nuclear launch keys? 🤔
...I may be overthinking this.
I scrolled down to comment just that. Damn xz attack is making us all paranoid.
4 Likes, Who?
Don't want to spoil the fun here. But this situation is rather similar to the xz vulnerability. Original dev overworked, other one jumps in. Makes all kinds of changes. Who is es20490446e? Does the software need root access? Ring zero? Nuclear launch keys? 🤔
...I may be overthinking this.
My gut says you're overreacting, but it's a good and secure way of thinking, so I'll answer your questions to the best of my ability.
This software needs root.
Differences:
the changes they made fixed actual issues users were having and other devs(for example nwilder) were dealing with instead of an issue that exist only in the issues without anyone we trust reporting existing issues.
Also this maintainer asks actively for issues to fix.
This project isn't very useful and as such popular for servers, which are the main targets on the linux ecosystem.
I checked the changes and found no Binary changes.
The old maintainer had archived the project already for some time before the current took over, meaning that the project had already had some time to decline in popularity, because of lack of support.
Things that are the same:
New maintainer and overworked old maintainer.
Edit:
also this is python based, so more people can actually understand their changes.
With my basic scrolling I found nothing directly alarming.
Last edited by LoudTechie on 9 June 2024 at 8:35 pm UTC
4 Likes, Who?
Damn xz attack is making us all paranoid.Better to be paranoid than complacent, though!
4 Likes, Who?
Don't want to spoil the fun here. But this situation is rather similar to the xz vulnerability. Original dev overworked, other one jumps in. Makes all kinds of changes. Who is es20490446e? Does the software need root access? Ring zero? Nuclear launch keys? 🤔
...I may be overthinking this.
My gut says you're overreacting, but it's a good and secure way of thinking, so I'll answer your questions to the best of my ability.
This software needs root.
Differences:
the changes they made fixed actual issues users were having and other devs(for example nwilder) were dealing with instead of an issue that exist only in the issues without anyone we trust reporting existing issues.
Also this maintainer asks actively for issues to fix.
This project isn't very useful and as such popular for servers, which are the main targets on the linux ecosystem.
I checked the changes and found no Binary changes.
The old maintainer had archived the project already for some time before the current took over, meaning that the project had already had some time to decline in popularity, because of lack of support.
Things that are the same:
New maintainer and overworked old maintainer.
Edit:
also this is python based, so more people can actually understand their changes.
With my basic scrolling I found nothing directly alarming.
But what if they learned from the xz experience, and now they are going to work on building trust for a year by doing real work before sneaking in an attack?
(Alright, alright, *this* project is not widespread enough, but the atacks are getting suffisticated enough that your argument is not enough)
3 Likes, Who?
Don't want to spoil the fun here. But this situation is rather similar to the xz vulnerability. Original dev overworked, other one jumps in. Makes all kinds of changes. Who is es20490446e? Does the software need root access? Ring zero? Nuclear launch keys? 🤔
...I may be overthinking this.
My gut says you're overreacting, but it's a good and secure way of thinking, so I'll answer your questions to the best of my ability.
This software needs root.
Differences:
the changes they made fixed actual issues users were having and other devs(for example nwilder) were dealing with instead of an issue that exist only in the issues without anyone we trust reporting existing issues.
Also this maintainer asks actively for issues to fix.
This project isn't very useful and as such popular for servers, which are the main targets on the linux ecosystem.
I checked the changes and found no Binary changes.
The old maintainer had archived the project already for some time before the current took over, meaning that the project had already had some time to decline in popularity, because of lack of support.
Things that are the same:
New maintainer and overworked old maintainer.
Edit:
also this is python based, so more people can actually understand their changes.
With my basic scrolling I found nothing directly alarming.
But what if they learned from the xz experience, and now they are going to work on building trust for a year by doing real work before sneaking in an attack?
(Alright, alright, *this* project is not widespread enough, but the atacks are getting suffisticated enough that your argument is not enough)
Maintainer replacement is a rare event.
Big projects are often maintained by the same person for more than 10 years.
The xz attack was "just" ~3 years of work, because they correctly predicted(not as impressive as it sounds) a maintainer that had already been maintaining a valuable project for a long time, who would snap within a manageable amount of time.
For this reason they basically immediately enabled the malware function after this rare event of, which they benefited.
If this maintainer replacement is contrary to the xz attack a cog in some larger more elaborate scheme instead part of the finishing blow, we're dealing here with an attacker with far more resources than the xz attacker(~6 years of dev team time instead of ~3 years, or 1+ election cycle instead of 1- election cycle).
My check ascertained me they're not running the same script as 90% of the current known maintainer replacement attackers.
Also maybe It eases you to know that es20490446e has been active for 7 years(, which is 4 years longer than Jian Tang) and has an inactive period of 3 years before that, which implies that they've had a healthy junior dev inferiority complex.
They also have a widespread widespread social media presence, which is less common among adversaries, because it makes it easier to trace you.
3 Likes, Who?
(Alright, alright, *this* project is not widespread enough, but the atacks are getting suffisticated enough that your argument is not enough)
And you are completely right being paranoid these days after the xz CVE stuff but, as LoudTechie said above, the guy has a profile of contributing to multiple other opensource softwares and he would be putting his reputation at jeopardy if he really wanted to widespread damage to laptops, or doing some nasty stuff with optimus-manager.
But yeah, these days being paranoic with software should be the modus operandi...
2 Likes, Who?
Hey, I wasn't expecting to see my project mentioned on GoL! I'm the original creator of optimus-manager (Askannz on Github).
And yeah I admit I haven't been working on it for a long time. It's less than I'm overworked and more that I just don't have the hardware for it anymore. My only testing machine is currently missing a hard drive, a right hinge, and is just generally falling apart (thanks MSI for your wonderful build quality), in addition to having a very old GPU that's not representative of modern Optimus variants. So I'm glad someone else has been picking up the slack. But in any case I'll be keeping an eye on new commits to make sure everything is going smoothly.
Last edited by Gazoche on 12 June 2024 at 12:36 am UTC
And yeah I admit I haven't been working on it for a long time. It's less than I'm overworked and more that I just don't have the hardware for it anymore. My only testing machine is currently missing a hard drive, a right hinge, and is just generally falling apart (thanks MSI for your wonderful build quality), in addition to having a very old GPU that's not representative of modern Optimus variants. So I'm glad someone else has been picking up the slack. But in any case I'll be keeping an eye on new commits to make sure everything is going smoothly.
Last edited by Gazoche on 12 June 2024 at 12:36 am UTC
5 Likes, Who?
Patreon
PayPal
See more from me