Live data from Hacker News

Spoiling Linux Kernel with "sanctioned" code

printserver.ink

21–30 of 72 posts

Re: Spoiling Linux Kernel with "sanctioned" code

#21
post #5

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…

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

Re: Spoiling Linux Kernel with "sanctioned" code

#23
> 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?

Re: Spoiling Linux Kernel with "sanctioned" code

#24
post #20
post #5

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…

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

Mageia's also a fine European distro.

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

Re: Spoiling Linux Kernel with "sanctioned" code

#25
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.

Re: Spoiling Linux Kernel with "sanctioned" code

#26

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

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

Re: Spoiling Linux Kernel with "sanctioned" code

#27

> 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…

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.

Re: Spoiling Linux Kernel with "sanctioned" code

#28

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 s…

> So here’s the thing ...

That was very much not the thing. He's raising an interesting point, if true. Namely that sanctioned countries could severely damage the progress of Linux by supplying good patches.

Re: Spoiling Linux Kernel with "sanctioned" code

#30

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

…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…

He's saying that they can not accept the same patch, even from someone else, once it's been submitted by a sanctioned country. It's little to do with getting a reply.

I haven't verified if what he's saying is true though.

Post reply on HN