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…
Spoiling Linux Kernel with "sanctioned" code
21–30 of 72 posts
Re: Spoiling Linux Kernel with "sanctioned" code
#22Is there a CVE for this?
Re: Spoiling Linux Kernel with "sanctioned" code
#23> 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
#24I'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".
Suse has more packages in their repo. But, I prefer Mageia's control center to yast.
Re: Spoiling Linux Kernel with "sanctioned" code
#25Greg 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
#26Obvious attack vector for Russia: Submit fixes to severe bugs that can't realistically be fixed any other way.
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…
Re: Spoiling Linux Kernel with "sanctioned" code
#28So 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…
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
#29Re: Spoiling Linux Kernel with "sanctioned" code
#30Obvious 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…
I haven't verified if what he's saying is true though.