Looks like GPU switching tool optimus-manager isn't abandoned yet

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.

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.

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

Damn xz attack is making us all paranoid.

Better to be paranoid than complacent, though!

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)

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.

(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...

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

(thanks MSI for your wonderful build quality)

That is a butterfly effect plot eh?

The well-known bad hinge on MSI laptops directly affecting an opensource software development process.