Spoiling Linux Kernel with "sanctioned" code

92 pointsposted a day ago
by ValdikSS

20 Comments

seanhunter

2 hours ago

So here’s the thing. The author thinks that Greg K-H is under some sort of obligation to respond to the patch they submitted. But that’s just not how free software works.

Greg K-H is a fully autonomous human being and he doesn’t work for the author of tfa. It sucks that we live in a world where nation states try to put exploits into the linux kernel and other foss projects but we very much do live in that world. It sucks that that means the author doesn’t get to contribute to the Linux kernel because their government (who they presumably have little control over) are very active in doing that, but that too is a fact of life.

Either way Greg K-H doesn’t owe you or me or the author anything and people need to stop being so entitled about free software.

NicuCalcea

2 hours ago

> Other people who would like to have this bug fixed can't commit it from their name or reuse the code present in the mail list from assumingly sanctioned entity

> The bug is forced to be fixed in some other way, not in a way it has been fixed by the bug fix contributor

I'm not quite following, why is this the case? If another non-Russian contributor submits the same fix, why wouldn't it be merged? If the project is GPL-licensed, surely that means the author of the fix doesn't retain any "patent" rights as the author describes it?

Simran-B

25 minutes ago

I suppose it's not about patents or copyright but rather the fear that a re-submitted patch can't be trusted because the original patch is considered not trustworthy, or that the resubmission is carried out by the sanction person itself or a friend under an email address that doesn't fall under the sanctions. Either way, it could be seen as a liability.

flashmozzg

19 hours ago

Is there a CVE for this?

eqvinox

2 hours ago

Why would there, it doesn't sound like a security issue?

thefounder

a day ago

I guess the Russians will have to learn the Chinese way and perhaps the Chinese language as well?

1attice

a day ago

I've been thinking lately that what underpinned the FOSS golden age was not actually decentralized VCS and high-quality forges, nor even ZIRP, but rather peacetime.

After a period of branches and patchsets, full national hard forks are going to become de rigeur, and linux-derived OSes across the world are going to bloom necessarily, as we no longer have the kind of ambient trust required to collaborate across borders.

Look forward to Euro-linux, Sino-BSD, and I guess probably some sort of GCC-area build as well.

Patches will be accepted across national boundaries with only the highest scrutiny, which itself will likely be provided by nationalized AI platforms.

Gods I hate this era

eqvinox

2 hours ago

It's even worse: the same logic is already starting to fracture the internet at large.

V__

2 hours ago

OpenSuse is (or will be) "Euro-Linux".

nosioptar

2 hours ago

Mageia's also a fine European distro.

Suse has more packages in their repo. But, I prefer Mageia's control center to yast.

gaiagraphia

8 hours ago

This is a great thing for innovation though? Nations/blocs protecting their tech interests will result in more jobs to go round in the industry, more unique ideas, and less centalisation, surely?

The globalised, hyper-centralised world is a bit boring, tbh.

1attice

5 hours ago

I forecast that you will not be bored, and may have other, stronger feelings. Ask Ukrainians

robobully

a day ago

This post is apparently not publicly shown on the main page for some reason.

ValdikSS

a day ago

Why should it be? It has low rating (yet).

gmerc

4 hours ago

Perfect usecase for AI, by US legal doctrine, copyright is gone after you feed it through and so should sanctions /s

mike_hock

a day ago

Obvious attack vector for Russia: Submit fixes to severe bugs that can't realistically be fixed any other way.

seanhunter

an hour ago

…and that’s an attack vector because?

There’s literally nothing stopping them from fixing the bug in either this case or the hypothetical. The maintainer just doesn’t respond to email from .ru domains. He could still choose to take the patch. He may just have decided not to accept this patch because changing something quite obscure to fix a weird printer used by one guy is likely to cause more problems than it solves. We don’t know because he didn’t respond.

That certainly doesn’t mean he wouldn’t fix a serious bug just because he heard about it from a .ru address.

_user_account

a day ago

Yeah, it sucks.

> This adds ~1ms latency per transfer cycle for rapid bidirectional communication which leads to half the USB 1.1 speed for smaller packets at best.

Still, I don't think this patch should be applied /for everyone/. Maybe compile out-of-tree and load as a kernel module, if possible?

ValdikSS

20 hours ago

The patch removes this latency and improves transfer speed, without any drawbacks.

M95D

3 hours ago

I still have a MB with just a USB 1.1 controller. I would hate it if the USB stopped working after this fix. I think a config option for the delay would be best.