Russische Linux-ontwikkelaars zijn verwijderd uit maintainerlijst kerneldrivers

Sommige Russische ontwikkelaars van Linux-kerneldrivers zijn vorige week uit de maintainerslijst gehaald vanwege 'verschillende compliance-eisen'. Hoofdontwikkelaar Linus Torvalds bevestigt dat het gaat om een bewust besluit.

Torvalds bevestigt dat verschillende Russische maintainers uit het opensourceproject zijn weggehaald, maar geeft daar geen reden voor. Volgens hem is het 'volkomen duidelijk' waarom deze verandering is doorgevoerd. De Linux-hoofdontwikkelaar stelt dat de wijziging niet ongedaan wordt gemaakt. Later laat hij nog weten dat hij niet ingaat 'op de details die ik en andere beheerders hebben gehoord van advocaten'.

Linux-ontwikkelaar Greg Kroah-Hartman bracht vorige week een patch uit waarmee verschillende ontwikkelaars, veelal met Russische namen en e-mailadressen, uit het maintainerbestand van de kernel werden verwijderd. Het gaat onder meer om beheerders van drivers die ondersteuning bieden voor hardware als laptops, embedded microcontrollers en socs, maar ook maintainers van het UFS-bestandssysteem. Hij liet daarbij enkel weten dat deze gebruikers zijn verwijderd 'vanwege verschillende compliance-eisen', en dat ze later weer kunnen worden toegevoegd 'als voldoende documentatie wordt verstrekt'.

Hoewel de beheerders zijn verwijderd, is de drivercode waar ze aan werkten vooralsnog onberoerd gelaten, waaronder die van drivers voor Russische hardware als de Baikal-T1-chips. Het is niet duidelijk of hun patches zullen worden toegevoegd aan de reguliere mainline kernel van Linux.

Reacties (95)

[bkor]

De personen welke zijn weggehaald werken voor een aantal Russische bedrijven. In het bestand zijn er nog genoeg Russische maintainers te vinden. Kijk je naar de patch dan lijkt het net alsof of het gaat om de nationaliteit, maar dat is dus een verkeerde conclusie. De actie is meer vanwege de (werk)relatie van deze mensen met een aantal Russische bedrijven.

[Wolfos]

Volgens een andere maintainer gaat het inderdaad specifiek om de bedrijven waar ze voor werkten, die op een sanctielijst zouden staan.
https://social.kernel.org/notice/AnIv3IogdUsebImO6i

[BlaDeKke]

Jammer dat het nieuwsbericht dit gemist heeft, lijkt me essentiële info.

[Reactie gewijzigd door BlaDeKke op 24 oktober 2024 21:30]

[Guru Evi]

Dan zou Linus toch een beetje duidelijker mogen zijn - hey die mensen werken voor de FSB is heel wat duidelijker dan "onze advocaat heeft gezegd".

[supersnathan94]

“Onze advocaat heeft gezegd” is anders wel exact wat je als bedrijf of persoon binnen die organisatie zou moeten zeggen.

Want ieder ander ding dag je zegt kan namelijk verkeerd worden uitgelegd.

[Guru Evi]

Maar dat gaat ook tegen alles in van de EFF, FSF en Linux in het algemeen. Ik heb al het gevoel gekregen dat Linus meer en meer onder druk staat van een schaduworganisatie binnen Linux Foundation of wie het ook is, of hij wordt ouder en zachter, maar meer en meer excuses aanbieden voor oa wat hij gezegt heeft dat historisch bekend was en volstrekt niet verkeerd is.

Dit is ook niet de eerste keer dat hij developers 'purged' ook van oa. China, Iran en anderen waar hij politiek niet overeenkomt, ik heb wel problemen met die landen, maar om zomaar mensen uit te sluiten van een "open source" project zonder bewijs dat ze iets verkeerd gedaan hebben gaat in tegen de geest van open source. En aan de andere kant laat hij het Rust project ook doen wat ze willen in die arena, waar Rust mensen de mond snoert als ze niet akkoord zijn of de naam Rust gebruiken.

Als het een probleem is met wettelijke dingen, daar is de EFF mee begonnen, ze zijn ondertussen al ver afgedwaald als organisatie maar hun eerste zaken bepaalde dat email en source code een beschermde vrijheid is met dezelfde beschermingen als schrijven en spreken, dat zou hier toch ook moeten aangehaald worden ongeacht wat een regering hiervan zegt.

[Reactie gewijzigd door Guru Evi op 24 oktober 2024 19:55]

[supersnathan94]

Ze kunnen er nog wel bij en ze hebben ook nog steeds het recht om aanpassingen te maken, ze hebben alleen geen rechten meer als Maintainer, om zaken door te duwen.

[Guru Evi]

Nee, volgens het artikel kunnen ze volstrekt geen aanpassingen meer aanbieden, het is niet gewoon een titelverandering, dat zou wettelijk gezien, moest er een echte wet zijn die Russen verbiedt deel te nemen aan open source projecten, niet voldoende zijn, dit zijn mensen die soms al jaren over een specifiek gebied van Linux (een driver of subsysteem) verantwoordelijk zijn en nu niet meer mogen meehelpen.

Hier zijn de veranderingen en uitleg: https://lore.kernel.org/a...-tiptop-blip-09ed@gregkh/

Om zaken door te duwen moet de code door Linus (of in geval van afwezigheid Greg) afgetekend worden.

[Reactie gewijzigd door Guru Evi op 25 oktober 2024 03:48]

[MSalters]

Er is geen specifieke wet voor open-source projecten nodig, net zoals er geen specifieke wet nodig is voor closed-source software. Er is een specifieke wet voor bepaalde bedrijven.

[Guru Evi]

Maar niemand haalt die wet aan, er is maar wat gekonkel over advocaten en Linus zegt dat als Fin hij niet van Russen houdt. En nogmaals, de FSF en EFF hebben historisch gezien die vrijheden verdedigd, echter nu kiest iedereen een kant in een conflict. Er zijn verschillende organisaties die oa root DNS beheren en IP blokken uitgeven die expliciet opgezet zijn dat ze ook doorheen een oorlog geen kant kiezen.

Daarnaast is Linux een internationaal project, geen eigendom van een land of bedrijf. Al die mensen hebben hun eigen toevoegingen gedaan, dus ze zijn deels eigenaar van het project.

[MSalters]

De bulk van de Linux contributors valt onder Amerikaanse of Europese (sanctie)wetten. Dat kun je wel zeggen dat Linux een internationaal project is, maar "projecten" zijn juridisch geen entiteiten. Intel, AMD, ARM Ltd, QualComm, NVIdia zijn dat allemaal wel. Linux is niet dom: een Linux fork die gesteund wordt door die partijen wint van een Linux fork die door Russen en Chinezen wordt gerund.

Evengoed kunnen Chinezen en Russen de huidige code blijven gebruiken, dat valt niet onder sancties.

[Guru Evi]

Ik zeg natuurlijk niet dat ze Linux moeten forken, ik zeg dat Linus en de FSF/EFF die vrijheden moeten verdedigen, en daar moet je inderdaad soms wetten voor 'overtreden', anders heb je geen standing in de rechtbank. Denk je echt dat ze het Linux project in de gevangenis zouden gooien?

De root DNS, IETF zijn ook grotendeels Amerikaanse/Europese projecten, zo ook de ISS, CERN etc. moeten we nu allemaal de Russen, Iraniers, Chinezen, Afrikaanse en andere landen buitensmijten elke keer er een (relatief kleine) oorlog is?

[Reactie gewijzigd door Guru Evi op 25 oktober 2024 22:43]

[sebati]

Ik zou de oorlog in Ukraine niet als klein willen bestempelen. Ok, als je het met de impact van WO2 vergelijk is het van een andere orde, maar we leven nu ook in een andere tijd met andere (geschreven en ongeschreven) regels. Een relatief kleine oorlog heeft een hoge economische imact, omdat we economisch in meer of mindere mate sterk van elkaar afhankelijk zijn. Bekijk alleen al de impact van deze oorlog op landen binnen de EU. Daar weeg ook mee dat het om annexatie gaat van delen van een buurland en niet enkel het uitschakelen van dreigingen uit een buurland.

Ik zou dus willen stellen dat het een vertrouwensbreuk is, de russische ontwikkelaars komen dus in een andere vertrouwenscirkel terecht en hebben daarmee niet meer de rechten binnen heb project welke ze tot nu toe genoten. Neemt niet weg, omdat de code open source is, zij gewoon nog de code kunnen gebruiken en hun eigen aanpassingen kunnen maken en/of deze aanpassingen op een andere wijze aanleveren bij het project. Zal allemaal een wat langduriger traject worden, minder efficient, vertragend werken, etc. Vanzelfspreken hebben ze al een kopie van alle code, zou mij hoogst verbazen wanneer 'andere werelddelen' dit niet op gezette tijden zouden doen. Een volledige blokkade tot de code heeft dan ook niet zoveel zin.

[Jerie]

Ik heb al het gevoel gekregen dat Linus meer en meer onder druk staat van een schaduworganisatie binnen Linux Foundation of wie het ook is, of hij wordt ouder en zachter, maar meer en meer excuses aanbieden voor oa wat hij gezegt heeft dat historisch bekend was en volstrekt niet verkeerd is.

En ik heb het gevoel dat Poetin's aura lekt. Hebben we niks aan.

[jja2000]

Nikita Travkin, of TravMurav in verschillende postmarketOS en arm64 linux gerelateerde chats doet dit voor z'n hobby en gebruikt zijn persoonlijke e-mailadres.

Het lijkt eerder compleet random...

[Jerie]

Of hij zegt dat hij het voor zijn hobby doet, en de persoonlijke e-mail is daarbij een cover. Dat weet je niet. Rusland is een autoritair land; het kan zomaar zijn dat hij onder druk wordt gezet. En ik denk dat het hem daar in zit.

[jja2000]

Ik ben het in die zin absoluut ook wel eens met de maatregel, het probleem is alleen dat er niet heel transparant over wordt gecommuniceerd. Ze passen het ook niet projectbreed toe of iets dergelijks. T'is gewoon super vaag.

[MSalters]

De kernel list post geeft aan dat het met voldoende documentatie teruggedraaid kan worden. Als hij op de loonlijst staat van een gesanctioneerd bedrijf, dan zal hij moeten bewijzen dat het écht privé doet.

[bkor]

Het lijkt eerder compleet random...

Je redenering is een beetje kort voor deze conclusie, niet?

Werken ze voor bedrijven welke een sanctie hebben of niet? Dat lijkt me duidelijker. En begrijp niet helemaal waarom een "ik doe het als een hobby" acceptabel zou zijn indien ze toch voor de bedrijven werken, dat is toch een behoorlijk legaal risico. Ik zou dat risico niet willen nemen namelijk.

[yevgeny]

From: Serge Semin

Subject: linux: Goodbye from a Linux community volunteer

Hello Linux-kernel community,

I am sure you have already heard the news caused by the recent Greg' commit
6e90b675cf942e ("MAINTAINERS: Remove some entries due to various compliance
requirements."). As you may have noticed the change concerned some of the
Ru-related developers removal from the list of the official kernel maintainers,
including me.

The community members rightly noted that the _quite_ short commit log contained
very vague terms with no explicit change justification. No matter how hard I
tried to get more details about the reason, alas the senior maintainer I was
discussing the matter with haven't given an explanation to what compliance
requirements that was. I won't cite the exact emails text since it was a private
messaging, but the key words are "sanctions", "sorry", "nothing I can do", "talk
to your (company) lawyer"... I can't say for all the guys affected by the
change, but my work for the community has been purely _volunteer_ for more than
a year now (and less than half of it had been payable before that). For that
reason I have no any (company) lawyer to talk to, and honestly after the way the
patch has been merged in I don't really want to now. Silently, behind everyone's
back, _bypassing_ the standard patch-review process, with no affected
developers/subsystem notified - it's indeed the worse way to do what has been
done. No gratitude, no credits to the developers for all these years of the
devoted work for the community. No matter the reason of the situation but
haven't we deserved more than that? Adding to the GREDITS file at least, no?..

I can't believe the kernel senior maintainers didn't consider that the patch
wouldn't go unnoticed, and the situation might get out of control with
unpredictable results for the community, if not straight away then in the middle
or long term perspective. I am sure there have been plenty ways to solve the
problem less harmfully, but they decided to take the easiest path. Alas what's
done is done. A bifurcation point slightly initiated a year ago has just been
fully implemented. The reason of the situation is obviously in the political
ground which in this case surely shatters a basement the community has been built
on in the first place. If so then God knows what might be next (who else might
be sanctioned...), but the implemented move clearly sends a bad signal to the
Linux community new comers, to the already working volunteers and hobbyists like
me.

Thus even if it was still possible for me to send patches or perform some
reviews, after what has been done my motivation to do that as a volunteer has
simply vanished. (I might be doing a commercial upstreaming in future though).
But before saying goodbye I'd like to express my gratitude to all the community
members I have been lucky to work with during all these years. Specifically:

NTB-folks, Jon, Dave, Allen. NTB was my starting point in the kernel upstream
work. Thanks for the initial advices and despite of very-very-very tough reviews
with several complete patchset refactorings, I learned a lot back then. That
experience helped me afterwards. Thanks a lot for that. BTW since then I've got
several thank-you letters for the IDT NTB and IDT EEPROM drivers. If not for you
it wouldn't have been possible.

Andy, it's hard to remember who else would have given me more on my Linux kernel
journey as you have. We first met in the I2C subsystem review of my DW I2C
driver patches. Afterwards we've got to be frequently meeting here and there -
GPIO, SPI, TTY, DMA, NET, etc, clean/fixes/features patch(set)s. Quite heat
discussions in your first reviews drove me crazy really. But all the time we
managed to come up with some consensus somehow. And you never quit the
discussions calmly explaining your point over and over. You never refused to
provide more detailed justification to your requests/comments even though you
didn't have to. Thanks to that I learned how to be patient to reviewers
and reviewees. And of course thank you for the Linux-kernel knowledges and all
the tips and tricks you shared.

* Andy, please note due to the situation I am not going to work on my DW DMAC
fixes patchset anymore. So if you ever wish to have DW UART stably working with the
DW DMA-engine driver, then feel free to pick the series up:
Link: https://lore.kernel.org/[e-mail]/

Linus (Walleij), after you merged one of my pretty much heavy patchset in you
suggested to me to continue the DW APB GPIO driver maintaining. It was a first
time I was asked to maintain a not-my driver. Thank you for the trust. I'll
never forget that.

Mark, thank you very much for entrusting the DW APB SSI driver maintenance to
me. I've put a lot of efforts into making it more generic and less errors-prune,
especially when it comes working under a DMA-engine control or working in the
mem-ops mode. I am sure the results have been beneficial to a lot of DW
SPI-controller users since then.

Damien, our first and last meeting was at my generic AHCI-platform and DW AHCI
SATA driver patches review. You didn't make it a quick and easy path. But still
all the reviews comments were purely on the technical basis, and the patches
were eventually merged in. Thank you for your time and experience I've got from
the reviews.

Paul, Thomas, Arnd, Jiaxun, we met several times in the mailing list during my
MIPS P5600 patches and just generic MIPS patches review. It was always a
pleasure to discuss the matters with such brilliant experts in the field. Alas
I've spent too much time working on the patches for another subsystems and
failed to submit all the MIPS-related bits. Sorry I didn't keep my promise, but
as you can see the circumstances have suddenly drawn its own deadline.

Bjorn, Mani, we were working quite a lot with you in the framework of the DW
PCIe RC drivers. You reviewed my patches. I helped you to review another patches
for some time. Despite of some arguing it was always a pleasure to work with
you. Mani, special thanks for the cooperative DW eDMA driver maintenance. I
think we were doing a great work together.

Paolo, Jakub, David, Andrew, Vladimir, Russell. The network subsystem and
particularly the STMMAC driver (no doubt the driver sucks) have turned to be a
kind of obstacle on which my current Linux-kernel activity has stopped. I really
hope that at least in some way my help with the incoming STMMAC and DW XPCS
patches reviews lightened up your maintainance duty. I know Russell might
disagree, but I honestly think that all our discussions were useful after all,
at least for me. I also think we did a great work working together with Russell
on the DW GMAC/QoS ETH PCS patches. Hopefully you'll find a time to finish it up
after all.

Rob, Krzysztof, from your reviews I've learned a lot about the most hardwary part
of the kernel - DT sources and DT-bindings. All your comments have been laconic
and straight to the point. That made reviews quick and easy. Thank you very
much for that.

Guenter, special thanks for reviewing and accepting my patches to the hwmon and
watchdog subsystems. It was pleasure to be working with you.

Borislav, we disagreed and argued a lot. So my DW uMCTL2 DDRC EDAC patches even
got stuck in limbo for quite a long time. Anyway thank you for the time
you spent reviewing my patches and trying to explain your point.

* Borislav, it looks like I won't be able to work on my Synopsys EDAC patchsets
anymore. If you or somebody else could pick them up and finish up the work it
would be great (you can find it in the lore archive). The patches convert the
mainly Zynq(MP)-specific Synopsys EDAC driver to supporting the generic DW
uMCTL2 DDRC. It would be very beneficial for each platform based on that
controller.

Greg, we met several times in the mailing lists. You reviewed my patches sent
for the USB and TTY subsystems, and all the time the process was straight,
highly professional, and simpler than in the most of my other case.
Thank you very much for that.

Yoshihiro, Keguang, Yanteng, Kory, Cai and everybody I was lucky to meet in the
kernel mailing lists, but forgot to mention here. Thank you for the time spent
for our cooperative work on making the Linux kernel better. It was a pleasure to
meet you here.

I also wish to say huge thanks to the community members trying to
defend the kicked off maintainers and for support you expressed in
these days. It means a lot.

A little bit statics of my kernel-work at the end:

Signed-off patches: 518
Reviewed and Acked patches: 253
Tested patches: 80

You might say not the greatest achievement for seven years comparing to some
other developers. Perhaps. But I meant each of these tags, be sure.

I guess that's it. If you ever need some info or consultation regarding the
drivers I used to maintain or the respective hardware or the Synopsys IP-cores
(about which I've got quite comprehensive knowledge by this time), feel free to
reach me out via this email. I am always willing to help to the community
members.

Hope we'll meet someday in more pleasant circumstances and drink a
couple or more beers together. But now it's time to say good bye.
Sorry for a long-read text. I wish good luck on your Linux-way.

Best Regards,
-Serge(y)

[jerisson]

Er is ondertussen wat meer info.
Bron: https://lore.kernel.org/[e-mail]/

Please accept all of our apologies for the way this was handled. A
summary of the legal advice the kernel is operating under is

If your company is on the U.S. OFAC SDN lists, subject to an OFAC
sanctions program, or owned/controlled by a company on the list, our
ability to collaborate with you will be subject to restrictions, and
you cannot be in the MAINTAINERS file.

Anyone who wishes to can query the list here:

https://sanctionssearch.ofac.treas.gov/

In your specific case, the problem is your employer is on that list.
If there's been a mistake and your employer isn't on the list, that's
the documentation Greg is looking for.

I would also like to thank you for all your past contributions and if
you (or anyone else) would like an entry in the credit file, I'm happy
to shepherd it for you if you send me what you'd like.

Again, we're really sorry it's come to this, but all of the Linux
infrastructure and a lot of its maintainers are in the US and we can't
ignore the requirements of US law. We are hoping that this action
alone will be sufficient to satisfy the US Treasury department in
charge of sanctions and we won't also have to remove any existing
patches.

Regards,

James Bottomley

[Stetsed]

Ik ben nog niet door alle LKML gegaan, maar van wat ik wel op kon pakken gaat het niet zozeer dat ze Russisch zijn, maar dat ze op lijsten staan zoals de Special Designated Nationals List(1) of dat ze connectie hebben met een entiteit die daar op staat.

Ik dat dit ook niet bevestigen maar blijkbaar was 1 van de maintainers werkend bij een bedrijf dat services leverde aan de Russische militaire?

En het is ook niet dat ze niks meer mogen geven aan de kernel, ze zouden in theory nog wel een commit mogen geven alleen hebben ze de maintainership rechten verloren, wat betekent dat ze naar een maintainer moeten stappen die het de kernel binnen brengt.

werkten vooralsnog onberoerd gelaten,

Ik weet ook niet wat met deze comment bedoelt wordt? De Linux Kernel werkt waar er werk is gewild, dus als er blijkt dat een andere maintainer dat werk niet over wou nemen dan gebeurt dat niet. Maar in theory kan het well gewoon want als er code wordt gegeven dat moet de developer een CLA tekenen, dus als iemand de moeite er in zou willen steken zou deze coden nog well de kernel in kunnen komen.

Update:
Ik ben even door de mailing list gegaan met de responses op de commit die de maintainers weghaalde. Ik zou zeggen dat ik het well eens ben met sommige dat ze meer publiek hadden kunnen zijn met de redenen achter het weghalen, het ook niet raar moet zijn.

Een van de weg-gehaalde maintainers is voor de "-MIPS BAIKAL-T1 PLATFORM", BAIKAL is een CPU maker uit Rusland, ik kan natuurlijk niet zeggen waarvoor ze die maken maar op dit moment staat er een verbod op bijna alle moderne processors op de import, dus ik kan well een beetje gokken. We zien ook dat BAIKAL of the hiervoor genoemde SDN lijst staan[3] als we BAIKAL zoeken op de lijst. En het is niet "Russiche" ontwikelaars want zelfs na het weg-halen zijn die er zeker nog[4]

[1]. https://ofac.treasury.gov/faqs/topic/1631
[2]. https://lore.kernel.org/a...-tiptop-blip-09ed@gregkh/
[3]. https://sanctionssearch.ofac.treas.gov/
[4]. https://github.com/torvalds/linux/blob/master/MAINTAINERS

[Reactie gewijzigd door Stetsed op 24 oktober 2024 16:40]

[RobertMe]

[...]


Ik weet ook niet wat met deze comment bedoelt wordt? De Linux Kernel werkt waar er werk is gewild, dus als er blijkt dat een andere maintainer dat werk niet over wou nemen dan gebeurt dat niet.

Andere sites schrijven iets in de zin van "de code die door deze maintainers is ingediend is niet teruggedraaid" of iets met die strekking. Dat lijkt mij een stuk logischer. Het is dus "de rollen zijn ingetrokken" en niet "alles wat ze ooit gedaan hebben is in twijfel getrokken en alles is verwijderd/teruggedraaid en wordt niet meer vertrouwd". En dat zal vast ook de intentie zijn geweest van die zin in dit artikel op Tweakers.

[CH4OS]

Wat de redenen ook zijn, de code is gelukkig altijd open source, dus inzichtelijk voor iedereen om te checken wat de aanpassingen doen en of die aanpassingen dan gewenst zijn of niet. Zou er bijvoorbeeld (met mijn alu hoedje op) een backdoor er in zitten, werd dat echt wel snel opgemerkt en weggepoetst of zelfs niet gemerged. In dat op zicht is er in elk geval weinig reden om bang te zijn voor backdoors bijvoorbeeld.

[whiner]

Ja want we checken altijd alle miljoenen regels code dat de linux kernel bevat.
Ik denk dat het niet zo moeilijk is om rotzooi te verbergen in een paar miljoen regels code.

[himlims_]

er is niemand die al die miljoenen regels nakijkt, dat gaat per commit + toelichting/comments, die worden gecontrolleerd. op die manier zit er wel een vorm van controle op de inhoud.

[XenoniaN]

Zie ook het hele xz- backdoor verhaal. Je kan het lastig uitsluiten.

Ik snap waarom deze keuze is gemaakt, al is het enorm zuur voor de vele eerlijke ontwikkelaars die hier ook door worden geraakt.

[poktor]

Dit inderdaad. Maar de goeden die ertussen zitten zullen ook wel snappen dat het risico gewoon te groot is.

[svennd]

Ik betwijfel of de developers eigenlijk getarget worden. Ik vermoed dat "compliance" niks wil weten van (semi) russische software. XZ was een stuk eenvoudiger, er was maar één single developer die moest uitgeschakeld worden. Bij de kernel is er hopelijk wel wat meer volk die meekijkt.

[Nielssss]

xz backdoor ging ook niet via de source code, maar de binaries. De code doorlezen zou niks uitmaken voor deze backdoor

[Pep7777]

Een vorm van controle wel. Maar ook weer niet, commits die niet gerelateerd lijken kunnen samen net dat ene "bugje" mogelijk maken. Dus zolang iedereen maar een klein stukje bekijkt...

[himlims_]

zijn (geautomatiseerde) tools voor om dat te debuggen - en als er toch een bug doorheen komt, is vaak een dagje later een commit om te verhelpen

[gitaarwerk]

ik heb zelf relatief simpele exploits geschreven, en die zijn echt niet door automatische tools gevonden. Daar stond ik redelijk van te kijken, want ze waren vrij generiek (en bedoelt ter leer en demonstratie). Meerdere tools.

Met die ervaring vertrouw ik die tools eigenlijk niet meer zo...

[uiltje]

Per definitie zal een tool niet zomaar alles kunnen vinden; uiteindelijk loop je als tool ontwikkelaar tegen het Halting probleem aan. Echter simpele code zou inderdaad gevonden moeten kunnen worden. Maar goed, ik hoopte ook dat de statistische code-analyse tools de meeste C++ geheugenoverschrijvingen (buffer overruns etc) zouden vinden. En die vinden ze ook wel, maar lang niet in elke situatie.

[MSalters]

Statische analyse kan doorgaans geen buffer overruns vinden. Dat kan alleen als de buffer grootte én de buffer offset beiden constant zijn. Dan kun je die twee vergelijken.

Dynamische analyse in C++ is ook niet zo ingewikkeld, want C++ heeft iterators. Daar zijn checked varianten van, die kijken of de iterator in range is wanneer die gebruikt wordt. C++ is OO, iterators zijn classes. Maar het probleem hier is dat de kernel nog C is, en pointers kun je niet zo simpel checken.

[uiltje]

Ik denk dat het een verkeerde vertaling van mij was. Static code analysis bedoelde ik natuurlijk, i.e. op de broncode ipv de runtime of het runnen van de SW. En idd gaat het dan vooral over het unmanaged gedeelte natuurlijk wat idd meestal in C is ipv C++.

[Reactie gewijzigd door uiltje op 25 oktober 2024 18:25]

[neh]

Ik vraag me af op basis waarvan je deze uitspraken doet. Zowel code reviews als static analysis (waar je denk ik op doelt) dienen om risico's te verkleinen, maar beide hebben hun beperkingen. Dat bugs vaak na een dag al opgemerkt worden is volgens mij ook uit de lucht gegrepen.

Het is bijzonder lastig om een committer met slechte intenties tegen te houden (zie bijvoorbeeld de xz backdoor eerder dit jaar).

[kozue]

Het is relatief simpel om er bewust een exploitable bug in te laten zitten. Als je expliciet backdoor code toe gaat voegen (zoals het openen van een poort en daarop maar calls luisteren) valt het heel snel op, maar een bewuste buffer overflow laten zitten zodat je er nog voor de commit al een exploit voor geschreven heb valt echt niet zomaar op. Niemand gaat de patch van anderen tot in detail debuggen.

[Scriptkid]

Vandaar dat we kaatst ook supply chains hadden in hardware die via linux distributie liepen en updates kregen.

Nee open source is zeker niet heilig.

[latka]

Ik denk het wel. Driverblobs daargelaten worden er alleen patches gestuurd. Als je patch een dikke kak aan wijzigingen is moet je praten als brugman voordat men uberhaupt je patch overweegt. Dus kak de kernel in krijgen is tricky. Als het al lukt is het een driver voor 1 device, maar zeker niet in de core.

Dus een backdoor in de Linux kernel verstoppen is niet lastig. De backdoor erin krijgen is wel heel moeilijk door het publiek die de patches moet accepteren.

[SniperBear]

Nee inderdaad, maar beter dan dat de Linux-ontwikkelaars wel goed gehandhaafd worden.

[k995]

Neen dat is een argument dat veel gegeven word maar nergens op slaat. Niemand zit door al die code te lopen om te zien op exploits. Per toeval zou dat men dat kunnen vinden of eerder: nadat die exploit gebruikt is .

[84hannes]

. Niemand zit door al die code te lopen om te zien op exploits.

Ik mag toch hopen dat de kernel een reviewproces heeft waarbij nieuwe regels wel worden gelezen door een reviewer of kernel maintainer.

[Reactie gewijzigd door 84hannes op 24 oktober 2024 17:13]

[Verwijderd]

Ja het gevaar is alleen dat als het gaat om meerdere devs die mogelijk malafide intenties hadden, je dus niet met zekerheid kunt zeggen of de reviewer ook niet iemand met bijbedoelingen was.

[k995]

Wikipedia: XZ Utils backdoor

dan was dit toch nooit gebeurt?

[84hannes]

Zoals je elders kunt lezen was het probleem daar dat een beheerder malafide was.

[Nielssss]

de binaries waren daar malafide, niet de source code. het checken van commits zouden dit niet voorkomen hebben

[aikebah]

De binaries waren niet malafide, de source tarball was malafide. Alle gecommitte code was in principe 'onschuldig' en enkel de handmatig bewerkte source-zip maakte van een deel van de bits van een ingecheckte testfile (die de nodige door de malafide beheerder handig gekozen bitjes bevatte, maar primair bedoeld was voor een test dat corrupted data conform verwachting afgehandeld werd) een exploit. Als je xz bouwde van de source-clone had je geen probleem, maar downloadde je de source tarball, dan zat er ineens een exploit in, omdat de source-tarball andere buildscripts bevatte dan de repository.

[Reactie gewijzigd door aikebah op 25 oktober 2024 17:00]

[Verwijderd]

ik weet niet hoe het met de kernel zit, maar wij laten periodiek onze software EN code toetsen door een externe PEN tester. Diens taak is het om exploits te vinden.

[RobertMe]

En uit hoeveel miljoenen regels code bestaat jullie codebase?

Bij het bedrijf waar ik werk is de code audit / pentest in ieder geval "gericht" op "waar is aan gewerkt sinds vorig jaar" / "waar willen jullie dat wij naar kijken". En dat gaat dan niet om een project van miljoenen regels code.

Nu een volledige security audit doen op de volledige Linix kernel is totaal niet te doen. En tegen de tijd dat je er klaar mee bent lig je alweer zover achter dat het mogelijk niks meer zegt omdat de ontwikkeling nog harder gaat.

Zie bv ook GitHub, die ook wel eens security audits doen met een team. En die hebben bv laatst naar Home Assistant gekeken een dagje en daarbij ook heel strict afgebakend dat ze alleen naar de login en API authenticatie zouden kijken. Dan kun je wel claimen "GitHub heeft Home Assistant geaudit", maar eigenlijk zegt het helemaal niks, omdat maar naar een heel specifiek (maar wel belangrijk!) deel is gekeken.

[aikebah]

Diens taak is het om door controles aannemelijk te maken dat er geen exploits in zitten bedoel je.
Meestal gaat dat met een beperkte scope, anders is het PEN-testen te duur en te langdurig.

[CH4OS]

Ik mag hopen dat er zowel een review proces is wat loopt voordat code van een ander blindelings wordt toegevoegd/vertrouwd. Daarnaast zijn er tegenwoordig ook (meestal als onderdeel van CI/CD straten) dat de code ook geautomatiseerd gechecked wordt, op o.a. backdoors etc. Ook dat is natuurlijk niet 100% waterdicht, maar zal allicht vast een stuk beter zijn en gevoeliger worden behandeld dan zoals bij XZ/xz (waar ik zojuist pas op gewezen ben).

[Frame164]

Vrijwel alle systemen met backdoors zijn in meer of mindere mate op Linux gebaseerd.

[RobertMe]

xz had alleen geen backdoor in de code zitten. De rogue maintainer had een "ongeldige" xz file in de repository gezet, wat dus gewoon een blob is. Alleen kwam er uiteindelijk 1 regeltje in de release die vanalles met deze blob deed en er al (verkapt) precompiled code in zat.

Bij xz is dus veel mis gegaan, op organisatorisch en technisch vlak. Maar een backdoor heeft (AFAIK) nooit echt in de code gezeten. Alleen werd er dus wel een rogue stuk precompiled code mee gecompiled/gelinkt/uitgepakt (op basis van de release zip. Een Git clone of GitHub source code download miste dat ene regeltje in de Makefile). Met degelijke code audits was dit dus nog steeds niet gevonden. Met degelijke code reviews / pull requests was het heel misschien voorkomen (maar nooit gevonden) op basis van een "geen blobs commiten [en voer tijdens build maar een begrijpelijk comm]"

[NoobishPro]

Ik ben minder fan van open source en de totaal onnozele claims dat het veiliger zou zijn, maar zelfs ik weet dat het per commit wordt bekeken en het vrij duidelijk is per commit waar wijzigingen in zijn gedaan... Dat is dan enkel kijken naar de gewijzigde code en niet de hele Kernel.

[svennd]

Niemand zit door al die code te lopen om te zien op exploits.

Ik zou vermoeden dat zowel red teamers, state actors als blue teamers op zoek zijn naar exploitable code. De street cred voor "I hacked linux kernel" is vrij hoog imho. (zie de artikels als een "Linux" exploit uitkomt)

[Vuurvoske]

Doet hoeft niet het geval te zijn, bij xz kwam het ook pas laat uit.

[Kees]

xz had maar 1 half afwezige developer. Bij de linux kernel gaan er wel iets meer ogen overheen.

[neh]

Prima, maar waar mensen werken worden fouten gemaakt anders was de kernel bugvrij. Een aanvaller met een doel kan listig te werk gaan en de bug verbergen of verspreiden over meerdere commits (of zelfs meerdere committers).

[Kees]

Klopt helemaal, maar persoonlijk verwacht ik dat die kans hoger is bij een kleine open source community of een closed source bedrijf (want die zullen ook niet allemaal een AIVD-level controlle bij hun medewerkers doen) dan bij de linux kernel.

[Scriptkid]

Of gewoon een zak geld aan de spprovers. Voor een miljoen of 5 zijn veel mensen om te kopen.

En een backdoor in linux leverd zo honderden miljoenen op.

[Blokker_1999]

Ben je daar zeker van? Uiteindelijk zit heel dat gegeven te bouwen op vertrouwen. Want wat als je verschillende van die geschrapte gebruikers hebt die elkaars werk controleerden en niemand anders keek er naar om omdat er toch controle was. Kan jij dan nog zeker zijn?

[WhatsappHack]

Dat dacht men ook bij OpenSSL. Kernel nog een stukje gevoeliger en zwaarwegender, sure. Maar toch.

[Bor]

Precies. Daarbij wordt wel eens vergeten dat er maar weinig mensen zijn die de skills hebben om echt een goede review te doen, security implicaties te doorgronden en hierbij afhankelijkheden te onderkennen. Het klinkt mooi "open source, dus iedereen kan controleren" maar in de praktijk blijkt dat toch vaak anders.

[ThaStealth]

Iedereen heeft de mogelijkheid om het te controleren, maar niet iedereen is capabel genoeg om het te controleren

[Frame164]

En mensen moeten er ook zin in hebben om het gestructureerd te doen. Nieuwe features ontwikkelen vinden de meeste ontwikkelaars leuker dan reviewen.

[wildhagen]

Dat het open source is, wil nog niet automatisch zeggen dat het 100% veilig is. Zie als recent voorbeeld dit: nieuws: Compressietool xz lijkt malware te bevatten, Linux-distro's waarschuwen

Het gaat om zulke grote hoeveelheden code dat niemand feilloos alles 100% kan overzien.

Dus ook hier zijn die maintainers wel degelijk een zeker risico. Hoe groot dat risico is, geen idee, maar zeker niet gelijk aan 0 in ieder geval.

Dit besluit lijkt me dan ook begrijpelijk en terecht.

[84hannes]

Dit besluit lijkt me dan ook begrijpelijk en terecht.

Mij ook, maar tegelijkertijd is het racistisch. Iemand afserveren als maintainer omdat hij of zij aantoonbaar in dienst is van de Rusische overheid snap ik. Iemand afwijzen vanwege zijn of haar nationaliteit of land van herkomst is onwenselijk. Maar backdoors zijn ook onwenselijk en niet onrealistisch, dus ik ben blij dat ik de keus niet hoefde te maken.

edit:
Volgens @bkor gaat het niet om afkomst maar om werkgever, dat maakt het al veel acceptabeler. Het zou fijn zijn als @Kevinkrikhaar daar naar kan kijken en het artikel (en de stellingsmakende kop) met voortschrijdend inzicht kan nuanceren.

[Reactie gewijzigd door 84hannes op 24 oktober 2024 16:28]

[uiltje]

Het probleem van de welwillende personen is natuurlijk wel dat ze in een land wonen waar je onder druk kan worden gezet om kwaadwillende dingen te doen. Ik vind het ook erg vervelend voor de individuen. Aan de andere kant dwingt het ook deze mensen nog eens extra om de oorlog niet te ontzien, of om het land te verlaten.

Het grootste probleem van de Russische bevolking is niet zozeer dat ze kwaadwillig zijn, maar dat ze achter "grote leiders" aanwandelen en vooral dat ze nogal onverschillig zijn. Kunnen we in de Westerse wereld ondertussen trouwens ook wat van met de komst van al die populistische partijen die gebouwd zijn rondom een persoon (Baudet, Wilders en die partij van Omzigt waar ik de naam me niet eens van herinner).

[downtime]

We zijn xz en OpenSSL alweer vergeten merk ik. Het is niet zo makkelijk als het klinkt, gezien de omvang en complexiteit van die code, en zeker niet met kernel- en drivercode. Er zit heel wat code in Linux waarvan niemand behalve de maker weet hoe het werkt en waarom het niet meer werkt als je er wat aan wijzigt.

[RobertMe]

Het verschil met xz is dat de schrijver van de backdoor daar zelf de releases deed. Bij Linux is het nog steeds Linus (of iemand dichter bij hem) die de patches moet accepteren. Dus ook al is er een maintainer die een patch indient waar een backdoor inzit dan zal er nog steeds iemand naar kijken. Nog los van dat patches volgens mij altijd door anderen "signed off" moeten zijn. Dus ook een maintainer zelf zou niet lukraak een patch naar Linus moeten kunnen sturen zonder dat iemand anders deze goedgekeurd heeft (of Linus er zelf er beter naar kijkt).

En daarnaast is XZ niet goed te vergelijken omdat de backdoor "soort van" alleen in de GitHub release download zat. Of beter gezegd, de backdoor zit in een blob verstopt, en deze wordt afgetrapt door een stuk code dat niet in de Git repository zat. De Git repository heeft AFAIK dus nooit echt een/de backdoor gehad. Dus ook daaruit blijkt weer dat er niet zomaar code met een backdoor is toegevoegd (maar de backdoor via een andere route is toegevoegd, in dit geval dus de GitHub release download waar deze persoon ook rechten toe had).

[Qwerty-273]

Het gaat juist om die periode tussen het plaatsen van ongewenste aanpassingen tot het ontdekken daarvan het het vervolgens terug draaien. Je zal dan specifiek elk stukje code door moeten nemen wat veel tijd zal kosten en waarvoor je ook voldoende expertise moet bezitten.

De oorzaak is natuurlijk sancties en daarmee of een stuk code als "Russisch" kan worden aangeduid of niet. Als je ontwikkelaars hebt die zich in Rusland lijken te bevinden, dan is dat al snel gemaakt, en je wilt niet het risico lopen dat daardoor een overheid (of meerderen) opeens Linux in de ban doen.

Of dat Amerikaanse bedrijven die mee ontwikkelen aan de Kernel opeens er mee moeten stoppen omdat het vanwege dezelfde sancties niet meer mag samenwerken met Russische entiteiten.

[morrowyn]

Helemaal mee eens hoor, dat open source iedereen in staat stelt om de code te analyseren. Echter had je vroeger de Underhanded C contest. Dus code at-face-value vertrouwen is misschien niet zo handig.

Er zitten zeer ingenieuze oplossingen tussen

,,The Underhanded C Contest is an annual contest to write innocent-looking C code implementing malicious behavior. In this contest you must write C code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should perform some specific underhanded task that will not be detected by examining the source code.,,

https://www.underhanded-c.org/_page_id_2.html

[lenwar]

Ik ben zelf niet zo goed in kerneldrivercode lezen. Kun jij het dan even checken of er geen rare recente dingen zijn toegevoegd?

Even serieus:
Kernel-code is vaak wel echt 2.0 en bijzonder moeilijk volledig te begrijpen. Het is lang niet voor ‘iedereen’ weggelegd.
Het verschilt natuurlijk per component, maar hardwaredrivers en bestandssystemen zijn echt mega-complexe code.

Zoals anderen al aangeven zegt het in de praktijk vrij weinig. De huidige maintainers van de kernel zijn een goed filter. (Alles wordt met minimaal 4 ogen gecontroleerd dacht ik.)
Diezelfde zie je in de praktijk ook gebeuren bij closed source of shared source producten, alleen is de openbare transparantie dan afwezig.

[The-Source]

Het stukje door iedereen te controleren klopt.
Kijk eens naar lib_xz utils waar ook iedereen het kon controleren maar iedereen dacht dat iemand anders dat wel deed.
nieuws: Compressietool xz lijkt malware te bevatten, Linux-distro's waarschuwen

[The Zep Man]

Dit hoeft natuurlijk geen gevolgen te hebben voor contributies door de betreffende ontwikkelaars. Die zullen nu wel hetzelfde proces moeten volgen als ieder ander die niet op de betreffende lijst staat.

[beerse]

Anders gesteld: Deze ontwikkelaars kunnen hun kernel ontwikkelingen nog wel indienen maar ze moeten dan door een kernel ontwikkelaar worden opgepakt en verwerkt. Een vorm van extra controle.

[Mellow Jack]

Voelt voor mij als een bom onder het hele opensource concept. Compliance technisch kan ik me erin vinden maar het is weer een push voor niet westerse landen om hun eigen initiatieven te pushen.

Volgende week in het nieuws "Rusland investeert miljarden in Huawei"

[beerse]

Voor mij is het juist het werk van open-source. Sommige ontwikkelaars krijgen het voordeel van de twijfel en kunnen/mogen met minder controle wijzigingen doorvoeren in de centrale code. Sommige onwikkelaars hebben de taak om de code van anderen te waarderen voordat ze in de centrale code worden opgenomen.

Maar die rechten kunnen ze ook weer worden afgenomen. Dat kan op basis van de acties die ze zelf hebben gedaan of juist het gebrek daaraan.

Volgende week in het nieuws "Rusland investeert miljarden in Huawei"

Dat zal mij niets verbazen, maar het vergelijkbare Huawei nieuws van deze week was van een andere orde.

[CH4OS]

Eigenlijk wil je vooral 'trust, but verify' toepassen met zulke zaken. Als het mis gaat, kán het behoorlijke gevolgen hebben... Dus je moet wel zeker zijn dat het klopt.

[Reactie gewijzigd door CH4OS op 25 oktober 2024 01:30]

[Verwijderd]

Doen ze nu al met het proberen lanceren van een BRICS munt. Het zomaar kunnen opleggen van sancties en geld blokkeren/stelen heeft het vertrouwen in de Westerse financiële markt dollar sterk doen dalen.

[Guru Evi]

Ik denk niet dat het de sancties etc zijn, er zijn genoeg wegen om errond te komen en geld representeert, het is niet noodzakelijk om de Amerikaanse overheid te betrekken in een transactie met een dollar, dus ongeacht van de sanctie heeft de dollar altijd een waarde.

Het probleem is dat momenteel de dollar (en de euro) enorm zwak staan, alhoewel niemand het wilt toegeven zitten we al een tijdje in een recessie/depressie, dus om ermee te handelen is een groter risico dan ooit, daarmee dat digitale munten en alternatieven, zelfs mensen die goud en andere metalen verhandelen ipv de (olie)dollar.

[The Zep Man]

Waarom zou een land nog willen deelnemen als dit betekent dat van zodra je tegen de wil van de VS ingaat, deze je geld zomaar kan wegnemen?

Geld is machtiger dan alles, en als land wil je handelen met het rijke Westen. Deelname voor de meeste landen is dan ook geen probleem, want de meeste landen gedragen zich niet als Rusland.

[litebyte]

Russische Linux-ontwikkelaars zijn verwijderd uit maintainerlijst kerneldrivers

"Sommige Russische ontwikkelaars..."

Ik zou in de kop ook "Sommige" vermelden, net als in de inleiding. Nu lijkt het uit de kop net alsof alle russische ontwikkelaars zijn verwijderd, dat is niet zo.

[RoestVrijStaal]

Ik ben benieuwd of deze trend ook doorwerkt in andere FOSS projecten zoals *BSD, Haiku, FreeDOS en ReactOS.
Vooral aan bij laatste blijken veel Russische ontwikkelaars eraan te werken.

In het verlengde daarvan gaat 7zip met Igor Pavlov en zelfs WinRAR met Eugene Roshal een dingetje worden.

[fiber44]

Er zitten mogelijk twee kanten aan dit verhaal. Kan me voorstellen dat het voor hun eigen veiligheid en die van hun familie ook beter is dat ze van de lijst gehaald zijn.

[janpiet]

Ik dacht dat Linux om vrijheid ging. Schijnbaar gaat deze vrijheid niet verder dan Washington en Wall Street.

[uiltje]

Echt, wat een waanzin. Mensen zijn kompleet gek geworden. Het is opensource dus backdoors, weinig kans zolang de code maar nagelopen wordt.

Nagelopen door wie? Er zitten meerdere russen in de lijst die voor specifieke Russische bedrijven werken.

Het is mij allang duidelijk dat de EU en USA alles doen om rusland klein te krijgen ...

Er zijn inderdaad sinds de Russische inval veel sancties in plaats, en die beginnen gelukkig ook hun vruchten af te werpen de laatste tijd. Aan de andere kant worden er nog steeds veel goederen en levensmiddelen toegelaten.

maar om dan opensource ontwikkelaars te bannen. Ik ben zelf veel veel met Samba bezig geweest en werd geholpen door een rus. Zeer goede knul die veel kennis van zaken had en wat blijkt, ook hij zit niet op dit soort onzin te wachten.

Er zijn zeker veel vriendelijke russen en ik had ook een Russiche dame in mijn vriendenkring zitten. Maar er is nog veel te weinig oppositie tegen de Russische machtshebber(s). Ik denk dat Oekraine ook niet op deze oorlog zat te wachten.

Wie heeft er uberhaupt bepaal dat die zomaar kan, wie is die dictator.

Meestal Linus, maar klaarblijkelijk zit er - volgens de berichtgeving - een heel juridisch team achter. Overigens hebben de meeste bedrijven een "dictator" genaamd CEO, met daarboven een controlestructuur van commissarissen. Bij Linus is dat ongetwijfeld de Linux Foundation.

Ik zie meer gevaar in de EU en USA dan Rusland. Ik kijk dan ook als jaren geen nieuws meer. Ik zal wel weer een min krijgen maar iemand moet het zeggen toch.

Als je geen nieuws meer kijkt moet je je buiten de politiek houden. Ik zie ook meer gevaar van EU en USA omdat hier idioten rondlopen die ook zomaar voor mogelijke dictators kiezen, en die zich van enigszins op feiten gestelde journalistiek links laten liggen omdat het niet in hun straatje past.

Als dit alles zo'n gevaar is, waarom worden dan ook, chinezen, Koreanen e.d. ook niet geweerd...

Ik vermoed dat Noord-Koreanen wel geweerd zullen worden, vooral ook omdat de burgers per definitie al geen internet (en meestal geen stroom) hebben. Chinezen is een lastiger verhaal, geen idee hoe dat zit. Ondanks de problemen in met de mensenrechten, de Chineze zee en de PRC / Taiwan heeft het nog geen soeverein land aangevallen. Het is ook niet op grote schaal bezig met beïnvloeding van verkiezingen of directe aanvallen op kritische infrastructuur zover ik weet. Rusland doet dat wel.

Aanvullend, ik hoop dat er nu veel meer mensen zijn die hun opensource werk stoppen.. eens kijken hoe dat dan gaat. Ik kan hier zo boos over worden..

En dat heeft voor jou welk voordeel precies? Of is dit gewoon een algemene verklaring van haat? Je hebt het hier klaarblijkelijk niet over jezelf, dus je draagt zelf niets bij neem ik aan?

En dat terwijl Ukraine met Amerika zelf die pijpleidingen opbliezen..

Dat was niet fraai inderdaad, hoewel de inkomsten van die industrie natuurlijk rechtstreeks de oorlogskas van Rusland instroomde. "Samen met Amerika" is neem ik aan een veronderstelling die je zonder enige aanleiding of bewijs hebt gedaan? Want dat komt niet overeen met de verhalen die ik erover gelezen heb.

waar is de 5 miljard die hugo kwijt maakte.

Mijn theorie is dat het is gebruikt om complot theorie-houders de mond te snoeren en af te betalen. Heeft niets te maken met het onderwerp, je bent hier maar wat aan het schreeuwen.

waarom worden de stukken van mh17 niet vrij gegeven

Aan wie, aan Rusland? Kom op zeg. Van MH17 is ondertussen erg duidelijk wat er gebeurd is, en zelfs welke personen er verantwoordelijk kunnen worden gehouden. Dat boek kan dicht, totdat er een vriendelijkere regering in Rusland zit.

waarom horen we niets over de rechtzaken omtrent de corona vax..
waarom komen die stukken niet boven water in de eu ondanks een gerechtelijk bevel? wat verbergt Ursula?
waarom stemde Nederland tegen de EU met 65% en zitten we er toch in.

Moeilijk te zeggen, je houd zelf het nieuws niet bij. Maar NVT. Verder is er gelukkig geen bindend referendum (meer). Mensen zijn namelijk redelijk kortzichtig en het is niet alsof Brexit erg goed is gelukt.

[Jerie]

Ik zie meer gevaar in de EU en USA dan Rusland.

En dat lijkt mij dan ook een prima samenvatting van jouw post want het geeft exact aan hoe jij er politiek in staat.

Ik sta er precies het tegenovergestelde in. De EU en VS hebben niet honderdduizenden soldaten verloren in een zinloze oorlog. Die bedreigen andere landen niet met kernwapens. Die hebben geen criminelen die verkrachten en stelen aan het front. Die bombarderen geen kinderziekenhuizen. Die beïnvloeden geen verkiezingen op de schaal zoals St. Petersburg dat doet. In die landen heb je een relatief fatsoenlijke vrijheid van meningsuiting. En ga zo maar door.

Wat mij betreft komen deze maatregelen 2.5 jaar te laat. Maar beter te laat dan niet.