Tablet: Fedora 33 Beta auf Surface Pro 4

Posted on by

Wieso würde ich Euch eine Nachricht antun, daß Fedora 33 Beta Linux auf meinem Tablet läuft? 🙂

Tablet: Fedora 33 Beta auf Surface Pro 4

Also ein Grund ist, das es Gnome 3.38 hat:

der andere Grund ist, daß es bis vor 10 Minuten nicht ging 😉

Im LiveImage von Fedora 33 kommen neue Grub Bootloader zum Einsatz und die starten nicht auf dem normalen Surface Pro 4, weil das wohl ein Firmware Update braucht, was es natürlich als reines Linux System nicht bekommen wird.

Ihr entsinnt Euch vielleicht an diesen Artikel: Fedora Guide – Falls der Grub2 Fix bei Euch versagt

Grub 2 hatte da einen bedauerliches Problem. Das wirkt sich nun scheinbar auf das Liveimage aus.

Beheben lies sich das durch ein Transplant der Grubbootloader in der Boot-Partition von F31 auf F33. Fedora ist dran, wird da aber ein kleines Problem haben, weil das Firmwareupdate von Microsoft kommen müßte.

GGf. können die Jungs vom Surface Kernel Projekt helfen, aber das wird sich erst in den nächsten Tagen entscheiden, denn noch wissen die nichts von Ihrem Glück.

PS: ich staune. Mein nur zu 77% gefüllter Akku soll angeblich noch 6 Stunden bei 4 Kernen und aktivem Turbo halten. Wie lange wäre das denn, wenn der voll wäre??? und schon sprang er auf 5h 45m. Verdacht: Es lügt mich in freundlicher Absicht an 😀

Hmm.. „Suspend“ funktioniert, der wacht sogar sofort wieder auf, wenn man auf den Power-Knopf drückt. Leider killt er dabei den Wifichip 🙁

UPDATE:

Stellt sich gerade raus, es ist wohl ein Timing Problem, denn 1 von ca. 10 Boots klappt und je schneller man bootet, nachdem der USB Stick eingesteckt ist, desto wahrscheinlicher der Start. Ich hoffe wir finden das raus. Der Grubsfiles sind da wohl nicht von Bedeutung.

CoronaChroniken: CVE für die Corona API von iOS und Android

Posted on by

Liebe Maskierte,

die meisten Leser, die wegen Corona hier sind, werden CVE-Nummern nicht kennen. Diese werden in der IT vergeben, wenn eine Sicherheitslücke gefunden wurde. Zu der Nummer gehört dann auch eine Risikoeinschätzung. Für die Corona-Melde-Api in iOS und Android wurde so eine Nummer beantragt, vergeben und bewertet.

CoronaChroniken: CVE für die Corona API von iOS und Android

Letzte Nacht erreichte uns auf der Full-Disclosure Mailingliste eine entsprechende Meldung von Dirk-Wilhelm van Gulik:

CVE-2020-24721: (Corona) Exposure Notifications API for Apple iOS and Google Android risk of coercion/data leakage post notification  / CVSS v3.1 score: 5.9

Die Schwachstellen wurden als „Mangel zum Schutz gegen Zwang“ und ein Informationsleck beschrieben, kurz zusammen gefasst: Selbst wenn die App gelöscht wird, wird in dem Teil des Betriebssystems in dem die ganze Technik für das Senden und Empfangen der Bluetooth untergebracht ist, der letzte Zustand gespeichert, weil die Anwendung darauf keinen Zugriff hat. Das bedeutet, ist die App einmal drauf und hat aktiv Daten gesendet oder empfangen, kann man das letzte Ergebnis nicht mehr vom Handy löschen. Damit kann ich nicht verhindern, daß jemand z.b. meine Aussendung „Ich bin ein Coronainfizierter“ aus dem (beschlagnahmten) Handy auslesen kann. Gleiches gilt für den Umstand, das man einen Hinweis eingeblendet bekommen hat, daß man einem Infizierten begegnet ist. Das widerspricht natürlich dem Gedanken, daß man seinem Handy trauen kann.

Bei Android und iOS gibt es implementierungsabhängige Abweichungen, aber im Prinzip leiden beide unter dem gleichen Problem. Eine Lösung, außer niemals die Apps zu benutzen, gibt es leider für Euch nicht, denn nur Google und Apple können das Problem lösen.

An die 16 Millionen die es schon installiert haben: Ihr seid gewarnt worden! Selbst Schuld.

Verursacht wird dies, weil das Handy immer die gleichen Identifikationsmerkmale erzeugt, die müssen ja schliesslich eindeutig sein, und dies natürlich auch dann tut, wenn jemand anders die App wieder installiert. Die Datensammlung scheint ~30 Tage lang zu laufen, also erst nach dieser Zeit kann man sicher sein, daß zumindest keine „Sie sind einem Coronainfizierten begegnet“ Meldungen mehr kommen. Das andere Problem ist nicht lösbar, außer die Daten werden im internen Speicher des OS gelöscht. Da hilft dann nur der Factory-Reset.

Nun ist das bereits im Januar bekannt geworden, weil es ein Systemimmanentes Problem ist (sieht Zeitstrahl unten). Warum die Apps trotzdem gemacht wurden und Google und Apple nichts dagegen getan haben, überlasse ich mal Eurer Fantasie, sofern Ihr welche habt. Auch wenn die Hinweise aus Holland kommen, die in den Handies verbauten Frameworks sind immer die gleichen, also gilt das auch für unsere deutsche App.

Glücklicherweise, wurde die App ist ja laut Amtsärzten derzeit als zweckfrei angesehen, also löscht die jetzt einfach und hofft darauf, daß Ihr in den nächsten 30 Tagen nicht von jemandem gezwungen werdet, sie erneut zu installieren.

Für Interessierte:

Variations of this flaw have been documented by the DP3T team in their academic paper. It was found it the Apple/Google implementations during the build of the dutch ‚Corona Melder‘ app (https://github.com/minvws).

2020-01-18 first known description of this class of issues
2020-04-03 first paper by DP3T team published.
2020-05-06 confirmation of this issue with Google
2020-05-07 confirmation of this issue with Apple
2020-08-13 final written/formal questions sent on request (#115 and 115.bis) as a vulnerability report.
2020-08-13 confirmation vendor. 2020-08-27 CVE issues by MITRE
2020-09-13 Request vendor to provide CVE/start FD.
2020-09-15 Versions under embargo sent to google/apple. Confirmation of receipt and reference # for both received.
2020-09-15 Full disclosure timeline setting process started.
2020-09-22 Reminder to google/apple & request to submit their preferred timeline/disclosure approach.
2020-09-25 Deadline to provide timeline preferences and feedback passed.
2020-09-29 Vendor informed that public disclosure is imminent.

 

 

Fedora: systemd-resolved Diskussion eskaliert

Posted on by

Wow, das habe ich nicht kommen sehen: Leonard Pöttering macht sich einen Feind fürs Leben, auf der Fedora-Devel Mailingliste 😐

Fedora: systemd-resolved Diskussion eskaliert

Das die Diskussion so schnell in einen Developerkrieg eskaliert, hätte ich nie für möglich gehalten:

„As we share the same employer, I encourage you to escalate my „derogatory behaviour“ to our magenement.

I did not read the rest of your email. I will not read or respond to further emails from you on mailing lists.“ (Paul Wouters, 29.9.2020 18:56 Uhr)

zu Deutsch:

„Da wir denselben Arbeitgeber haben, ermutige ich Sie, meine „abfälliges Verhalten“ unserem Arbeitgeber zu melden.

Den Rest Ihrer E-Mail habe ich nicht gelesen. Ich werde sie weder lesen, noch auf weitere E-Mails von Ihnen auf Mailinglisten antworten.“

Herr Pöttering schrieb dies vorher an die Mailingliste:

„“Custom“ is in the eye of the beholder. It appears to me you mean that in a derogatory way.

I mean, given that Ubuntu has been enabling systemd-resolved since quite some time by default I have the suspicion our codebase is more often deployed IRL than the ones you listed? I mean, maybe I am wrong, but it’s certainly not that this is exotic stuff as you imply.

I have the suspicion this is a territorial thing, no? It feels as if you believe that DNS clients that people wo are not core members of the DNS community are inherently a bad thing, and should go away, and leave the real work to the people who actually know how things work, right? I got that kind of behaviour once before when people told us to just leave service management to the real holy men of UNIX.“ (Leonard Pöttering, 29.9.2020 18:18 Uhr)

zu Deutsch:

„Kundenspezifisch“ liegt im Auge des Betrachters. Mir deucht, Sie meinen daß in abfälliger Weise.

Ich meine, angesichts der Tatsache, dass Ubuntu seit geraumer Zeit standardmäßig systemd-resolved aktiviert hat, habe ich den Verdacht daß unsere Codebasis häufiger IRL eingesetzt wird als die, die Sie aufgelistet haben? Ich meine, vielleicht irre ich mich, aber es ist sicher nicht so, dass dies so exotisch ist wie Sie andeuten.

Ich habe den Verdacht, dass dies eine territoriale Angelegenheit ist, nicht wahr? Es fühlt sich an, als ob Sie glauben, dass DNS-Clients, von Personen die keine Kernmitglieder der DNS-Kern-Gemeinschaft sind, von Natur aus eine schlechte Sache sind und verschwinden sollten, und überlassen Sie die eigentliche Arbeit den Menschen, die tatsächlich wissen, wie die Dinge funktionieren, richtig? Ich habe diese Art von Verhalten schon einmal erlebt, als man uns sagte „Überlassen Sie die Verwaltung der Dienste einfach den wahren heiligen Männern von UNIX“.“

Irgendwie kann ich beiden zustimmen, auf der einen Seite gibts extra eine teuer bezahlte Arbeitsgruppe bei der IETF, die Sachen entwicklen sollte, auf der anderen Seite kommen die nicht zu potte ( schreibt Pöttering einen Absatz später ). Trotzdem sehe ich das eher so, daß allein schon wegen fehlendem DNSSEC und dem Default Fallback zu Cloudflare und Google DNS-Servern, systemd-resolved nicht einfach so eingesetzt werden kann.

Angebot

Viele der Probleme, die resolved lösen soll, sind eherlich gesagt Luxusprobleme, die sich mit ein klein wenig Hirnschmalz lösen lassen. Bis auf ganz exotische Szenarien, wo jemand für alles, was er per Interface 1 erreichen kann, DNS 1und2  benutzen will und für Interface 2 dann DNS 3und4, reicht das. Wer ein echt komplexes Setup hat, mit VPN Tunneln durch VPN Tunnel der darf mir gern einen Leserbrief schicken und das mal darstellen. Dann schaue ich mir das gern mal an und gucke, ob das nicht einfacher geht. Herrn Pöttering habe ich auch um ein Beispiel angemailt, mal sehen ob eins kommt.

 

Fedora: Die DNS Geschichte trägt Früchte

Posted on by

Wer die Mailingliste von Fedora-Devel gelesen hat, wird es mit bekommen haben: Das Thema systemd-resolved & DNS trenden enorm.

Fedora: Die DNS Geschichte trägt Früchte

Als eine Konsequenz der Diskussion wurde ein Änderungsvorschlag der DNS Gruppe von Michael Catanzaro eingereicht, daß systemd-resolved ab sofort mit einem optimistischen DoT aktiviert wird, also DNS-over-TLS, dem älteren Bruder von DNS-over-HTTPS ( DoH ).

Das meint für den Benutzer, wenn ein eingestellter DNS Server DoT unterstützt, und das findet man leicht mit einem Connectversuch auf den passenden Port 853 heraus, soll automatisch die Verschlüsselung benutzt werden. Das ist natürlich aus Datenschutzgründen zu bevorzugen.

Der Nachteil der Sache ist leider, daß die DNS Anfragen nicht ganz so schnell kommen, wie man das gewohnt ist, weil ja mehr Daten und Verschlüsselung im Spiel sind. Es ist aber ein Weg in die richtige Richtung.

Ein bisschen laut Lachen mußte ich allerdings bei der Passage:

== Benefit to Fedora ==

DNS queries are encrypted and private by default, if the user’s ISP supports DoT. Most probably don’t, but users who manually configure a custom DNS server (e.g. Cloudflare or Google) will automatically benefit from DNS over TLS.

Ausgerechnet die beiden DNS Server zu empfehlen, die das Privatsspährenproblem im systemd-resolved sind, ist schon eine Farce 😀

 

Systemd: resolved verkauft User u.U. an Google und Cloudflare

Posted on by

Was so alles ans Licht kommt, wenn man Mailinglisten verfolgt. Quasi in einem Nebensatz hat Herr Pöttering kurz mal erklärt, daß systemd gegen die DSGVO verstößt.

Systemd: resolved verkauft User u.U. an Google und Cloudflare

Die DSGVO legt fest, daß alle Systeme die zum Einsatz kommen, in einer datenschutzfreundlichen Voreinstellung daher kommen müssen. Merkt Euch das mal für später.

Hier erstmal ein Auszug aus dem Posting von Herrn Pöttering:

„Also, people would react very allergic if we’d start sending all DNS traffic to google or so. I mean, you can’t believe how pissed people are that we have a fallback in place that if no DNS servers have been configured at all or acquired via DHCP we fall back to Cloudflare + Google DNS servers. Downstream distros (Debian…) tend to patch that fallback out even…“ (Fedora ML, 29.9. 10:19)

Meint auf deutsch:

„Außerdem würden Menschen sehr allergisch reagieren, wenn wir anfangen würden, alle DNS Verkehr zu googlen oder so. Ich meine, Sie werden es nicht glauben, wie sauer die Leute sind, dass wir einen Fallback haben, der, wenn überhaupt keine DNS-Server konfiguriert sind oder über DHCP erworben werden, greifen wir auf Cloudflare + Google DNS-Server zurück. Downstream-Distributionen (Debian…) neigen dazu, das sogar raus zupatchen …“

Oh, ja, da reagieren wir Menschen allergisch drauf, weil das einen Verstoß gegen den Datenschutz darstellt. Die Debinaleute sehen das ganz richtig. Man kann nicht einfach heimlich am Benutzerwunsch oder Adminunvermögen hinweg Daten an Google oder Cloudflare schicken. Wenn das in einer Firma, einem Verein oder einer Behörde passieren würde, dann wäre das ein DSGVO Verstoß der bestraft würde! Scheinbar hat hier jemand die Jahre 2016-2019 verschlafen, als die EU Gerichte mit so etwas aufgeräumt haben. Zur Erinnerung: US Privacy Shield .. zusammengebrochen, Facebook droht mit Rückzug aus der EU, Google & MS verlegen Ressourcen in die EU, damit sie weiter im Spiel bleiben können und dann kommt ein Systemd daher, der die DSGVO unterminiert.

Man stelle sich mal vor, eine größere Firma in der auch Linux als Desktop zum Einsatz kommt und dann steht in irgendsoeiner hart gecodeten .so drin, sie soll Google kontaktieren. Für alle die nicht wissen, was Datenschutz in Firmen heutzutage bedeutet:

  1. Zuerst muß man mal ermitteln wohin was für Daten abfließenund wen das genau betrifft
  2. Dann muß man eine Datenschutzfolgeabschätzung dafür machen
  3. Dann muß man geeignete Schutzmaßnahmen ergreifen.
  4. Das muß als Vorgang mit laufender Nummer in die Datenschutzmappe eingetragen werden.

Jetzt habe ich als Admin also einen DNS Cache für die Firma hingestellt und per DHCP teile ich dieses DNSCache allen PCs mit. Die PCs fragen also meinen DNS Cache und der fragt dann wen auch immer.Das DNS Cache wird also schon eine Reihe von meinen Abfragen so beantworten können, was den Datenschutzvorteil hat, daß der DNS, den das Cache wiederum fragt, nur einen Bruchteil davon sieht und so kein vollständiges Profil erstellen kann. Den DNS Cache ( z.b. nscd ) kann man auch per Round-Robin mehrere andere Server fragen lassen um die Profilbildung weiter zu erschweren.

Der Problemfall

Jetzt funktioniert der lokale DNS aber nicht, weil es ein Update gab, oder die VM abgestürzt ist. Systemd würde jetzt keine gültigen DNS bekommen und Google+Cloudflare fragen. Damit wäre meine komplette Datenschutzabschätzung fürn Arsch. Schlimmer noch ist der Umstand, daß diese Art Datenfluß als Vorgang überhaupt gar nicht in meiner Datenschutzmappe vorkommt. Zum Glück ist das ein minder schwerer Fall, den der Datenschutzbeauftragte selbst regeln kann, indem er den Vorfall in die Mappe einträgt und Maßnahmen ergriffen werden, dies zukünftig zu verhindern.

Sollte aber ein Datenschutzaudit ergeben, daß es diesen Abfluß gibt ohne das das intern gefunden wurde, sieht die Sache schon anders aus. Je nach Umfang könnte die Datenschutzbehörde ein Bußgeld verhängen und das nur weil einer, den keiner in der Firma kennt, meinte schlauer sein zu müssen, als alle anderen. Na danke!

Jetzt kommt der nächste Oberschlaue mit dem Hinweis, daß bei DSL ja eh alle die gleiche IP von der Firma haben und individuelle Profile gar nicht erstellt werden können und außerdem wären das ja keine privaten Domainanfragen. Das fällt bei größeren Firmennetzen seit IPv6 unter „Es war einmal..“ . Wenn ich einen Businesszugang mit einem reinen IPv6 Netz bekommen, habe ich einen ganzen Block zur Verfügung. Dies Netz kann ich direkt an alle Pcs durchreichen, denn dann habe ich kein NAT Problem mehr. Per Firewall kann ich den Direktzugang zu den Pcs sperren, kein Problem und wenn doch mal jemand von außen drauf muß, wären individuelle Freigaben möglich. Das muß man als Admin natürlich auch mit IPv6 nicht so machen, aber es wurde mal so vermarktet, als für IPv6 geworben wurde.

Das die meisten am Arbeitsplatz auch privat surfen, braucht man wohl kaum noch erwähnen.

Die Technisch -Organisatorischen Maßnahmen zum Datenschutz einer Firma ( TOM ) beinhalten alle Maßnahmen die man so als Firma macht und wenn da steht, wir leiten DNS über ein Cache zum minimieren von Profilbildungen, dann kann man da schlecht ein Linux betreiben, daß sich da nicht dran hält, oder seht Ihr das anders? Linux muß also auch in der Datenschutz freundlichen Einstellung daher kommen, was damit einen Einsatz von systemd-resolved ausschließt, da man sich da ja nicht drauf verlassen kann wie man oben sieht.

Update

Ein Leserbrief erreichte mich vorhin. Hier ist der Link, in dem das Fallbackfeature bei Systemd besprochen wird: https://github.com/systemd/systemd/pull/11666

Und gleich noch die Diskussion, wieso CloudFlare DNS besser wären: https://github.com/systemd/systemd/issues/8899

So richtig viel Gegenwind gabs aus der Peergruppe anscheinend nicht.

Fedora 33: der Wechsel zu systemd-resolved schaltet DNSSEC aus

Posted on by

Wow, was für eine Hammermeldung. Damit hatte vermutlich niemand gerechnet, daß der Wechsel zu systemd-resolved als DNS Resolver des Systems einfach mal die einzige Sicherheitsmaßnahme im DNS aushebelt, die überhaupt spürbar Sicherheit gebracht hat 🙂

Fedora 33: der Wechsel zu systemd-resolved schaltet DNSSEC aus

„Seit heute morgen 6:44 Uhr wird zurück geschossen“ :  Paul Wouters, bekannt aus dem Bereich Transparenz und Sicherheit der IETF, updatete seinen Server auf Fedora 33, was er quasi sofort bereut hat. Mit dem Wechsel kam die Umstellung auf systemd-resolved, über den wir vor Monaten in der Fedora Mailingliste gesprochen hatten und ich eigentlich der Meinung war, daß die Umstellung der /etc/resolv.conf hin zu systemd-resolved in der Form gar nicht kommt.

Man merkt, daß Paul bei seinem Posting an die Fedora-Devel-Mailingliste auf Krawall gebürstet war, und das vollkommen zu Recht. Seine ganzen Serverdienste benutzen DNSSEC um die Verbindungen zu Mailserver, VPN usw. abzusichern, so daß niemand für seine Dienste eine MITM-Attacke fahren kann und dann kann der eingesetzte DNS-Resolver plötzlich kein DNSSEC mehr:

„It is my opinion as a long time DNS RFC author and package maintainer that systemd-resolved is not a suitable DNS resolver. Downgrading DNSSEC allowing local DNS to bypass DNSSEC is bad enough, but I read on:

https://fedoraproject.org/wiki/Changes/systemd-resolved

that DNSSEC is now completely disabled. Again, this is completely unacceptable. DNSSEC is part of the core of DNS protocols.“ (Paul Wouters)

Ich hätte nicht gedacht, daß jemand wirklich so verrückt wäre, Millionen von PCs mit einem DNS-Resolver aus der Steinzeit zuversehen, wo das Update doch eine Verbesserung und kein Rückschritt sein sollte. Seinen weiteren Ausführungen kann man sich nur anschliessen:

„This change is harmful to network security, impacts existing installations depending on DNSSEC security, and leaks private queries for VPN/internal
domains to the open internet, and prefers faster non-dnssec answers over dnssec validated answers. It fails various types of queries,
misimplements part of the DNS protocol. Not only according to me, but to 20years+ developers of the bind software as well.

The first mandatory step is to not disable DNSSEC. If I put on my security hat, I would actually have to look into filing a CVE for Fedora 33.“ (Paul Wouters)

Und der Mann weiß was er da schreibt, er hat 20 Jahre an Bind mitgeschraubt. Zum Glück für uns ist nichts in Stein gemeiselt, daher jetzt die Befehle, um nach dem Upgrade für Ordnung zu sorgen:

sudo rm -f /etc/resolv.conf
sudo ln -sf /run/NetworkManager/resolv.conf /etc/resolv.conf
sudo systemctl disable –now systemd-resolved.service
sudo systemctl mask systemd-resolved.service
sudo systemctl reboot

Damit haben wieder die DNS Einstellungen das sagen, die der User beim Anlegen der Netzwerkverbindung getroffen hat. Ich finde ja schon lange, daß der Systemd sich deutlich zu weit aus dem Fenster hängt. Das ist ein Bootsystem und kein eigenes Betriebssystem Leonard! Aber stellt sich doch glatt raus, daß der resolved vom systed das könnte, wenn man es nur einschalten würde, was es per default nicht ist :facepalm:

 

Das Update ist der Anfang vom Ende

Posted on by

Noch letzte Woche habe ich einer Linux-Usergroup Sitzung die Material-Shell Erweiterung für Gnome gezeigt und für sinnvoll erklärt. Zum Glück bin ich kein Politiker.

Das Update ist der Anfang vom Ende

Das keine 5 Tage später mein vorsichtiges Empfehlen dieser Erweiterung zu einem rüden Stop kommen würde, konnte da noch keiner ahnen. Leider kann ich Euch nicht zeigen, wie die Material-Shell funktioniert, da sie sich sehr erfolgreich durch ein Gnome-Extensions-Update selbst zerbröselt hat.

Trotz diverser Versuche, inkl. Neustarts von Gnome, war ich nicht in der Lage die Erweiterung auf diesem Benutzeraccount wieder zum Laufen zu bekommen. Da darf man gespannt sein und vermutlich alles, was mit der Erweiterung zu tun hat wie „Config“,“Cache“,“Erweiterung selbst“ aus den Verzeichnissen löschen und dann von vorn anfangen. Ohne diese Maßnahme kommt es zur sinnlosesten Fehlermeldung ever: „Error“

Damit kann man als Gnome-Benutzer natürlich nichts anfangen, außer die Erkenntnis gewonnen zu haben, daß es sich da jemand sehr einfach gemacht hat. Zum Glück kann man mit der Looking-Glass Konsole von Gnome doch etwas erfahren, aber halt nur als Eingeweihter in die Tücken der Gnome-Erweiterungen. Diese sind z.Z. in Javascript geschrieben und können daher tatsächlich von Webentwicklern geändert werden, die JS verstehen. Das hilft zwar nicht immer, weil es kein Browser-JS ist, aber kleinere Fehler kann man beheben.

Eine Debugkonsole von Gnome mit InhaltWir haben also den Fehler „TypeError: GObject.registerClass() used with invalid base class ( is Source )“

Scheint also ein Programmierfehler zu sein in der neuen Version. Das hätte ja eigentlich beim Testen mal auffallen müssen. Mit einem Trick kann man das ganze „Retten“:

Mit Firefox ladet Ihr jetzt die V4 der Gnome-Erweiterung für die passende Shellversion (34) runtern:

Die gespeicherte Version ist ein ZIP File, das packt Ihr einfach aus und wechselt in das erstellte Verzeichnis.

Ihr macht nun einen zweiten Dateibrowser auf und navigiert nach: „./local/share/gnome-shell/extensions/material-shell@papyelgringo“ . Alles was Ihr findet wird gelöscht, der Ordner bleibt.

Dann kopiert Ihr den Inhalt des frisch ausgepakten ZIP Files in das leere Verzeichnis:

Zwei Dateibrowser mit Inhalt einer Gnome-Erweiterung beim kopieren von Dateien

Drückt „ALT+F2“ und gebt „r“ ein. Das startet Gnome neu und siehe, die Material-Shell geht wieder. Problem gelöst, aber Updates gibt es erstmal keine mehr 🙂

 

 

CoronaChroniken: The Walking Dead

Posted on by

Liebe Maskierte,

heute reden wir wieder über Sterbezahlen, einen kleinen Skandal und das RKI und ich befürchte… in Personalunion.

CoronaChroniken: The Walking Dead

Das uns das RKI als Bevölkerung nicht mehr mit täglichen Sterbefällen belästigen möchte, weil die sich nicht „dynamisch genug entwickeln“ um weiter von täglicher Bedeutung zu sein (siehe RKI Situationsbericht vom 14.9.) , muß ich mich doch wundern, daß andere Länder, nein private Firmen in den USA, da mehr und genauere Informationen bekommen, als das deutsche Volk vom eigenen dafür zuständigen Institut:

Worldometer is run by an international team of developers, researchers, and volunteers with the goal of making world statistics available in a thought-provoking and time relevant format to a wide audience around the world. It is published by a small and independent digital media company based in the United States.

Kleiner Auszug gefällig, was die derzeit Posten? Bitte schön:

Latest News

September 26 (GMT)

Updates

Updates

Updates

Updates

Updates

Quelle: https://www.worldometers.info/coronavirus/country/germany/

Deren Quelle ist wiederum der Tagesspiegel, also eine Zeitung, die wiederum berufen sich auf die Landkreise und „andere Quellen“. Eins muß man allerdings sagen, deren Interaktive Sektion ist gar nicht mal so schlecht, wenn man mal von den nicht namentlich genannten Quellen absieht. Es könnte also viel Fantasie im Spiel sein.

Geht es nach denen, dann sterben in Nordrhein-Westfahlen derzeit täglich 3-4 Menschen in Zusammenhang mit Covid-19, womit sie treibende Kraft für die Gesamtstatistik  wären, denn der Rest der Republik hat Null-Linie. Man siehts ja hier:

Wenn Ihr die Zahlen oben von Wordometer mit dem Graphen über diesem Satz vergleicht, Wird Euch auffallen, daß es keine Spitzen gibt, die aber bei 17 Toten am Tag sichtbar werden müßten. Fairerweise muß ich anmerken, daß mein Graph geglättet ist, weil wir ja nicht mehr die Tageszahlen vom RKI bekommen, sondern nur die Wochenzahlen.

Jetzt stellt sich die Frage, was stimmt denn nun? Das „keine dynamische Entwicklung“ vom RKI oder die Zahlen vom „Tagesspiegel“, die ja eine Dynamik in Nordrhein-Westfahlen zeigen?

Gemeinsam haben beide Quellen nur eins: Sie geben Zahlen wieder, die im täglichen Grundrauschen an Verstorbenen in der Bundesrepublik untergehen. Der Durchschnitt liegt um die 2.400 Personen am Tag. Solange der Durchschnitt sich nicht signifikant bewegt, ist bevölkerungsweit betrachtet auch nichts schlimmes passiert.

Von einer gefährlichen Welle kann man also nur sprechen, wenn man lediglich Infizierte im Blick hat, aber nicht Erkrankte. Meiner Meinung nach, ist aber die Zahl der Erkrankten ist entscheidend, nicht die der Infizierten.

Wie im April

Vor ein paar Tagen fiel mir dieser Satz im RKI Situationsbericht auf:

Aufgrund der geringen Zahl eingesandter Proben ist keine robuste Einschätzung zu den derzeit eventuell noch zirkulierenden Viren möglich. Seit der 16. KW 2020 gab es in den Sentinelproben keine Nachweise von SARS-CoV-2 mehr.

Sentinelproben kommen aus rund 100 Allgemeinen Arztpraxen, die pro Woche 3 Proben von Patienten mit grippeähnlichen Symptomen an die Arbeitsgruppe Influenza schicken, die dann auf alle Viren und Bakterien getestet werden. Damit erhält man einen Überblick, was alles so  im Umlauf ist. Die RKI-FAQ schreibt dazu:

Da momentan ein vergleichsweise kleiner Teil der Menschen hierzulande mit SARS-CoV-2 infiziert ist, ist die Wahrscheinlichkeit gering, dass ausgerechnet in diesen ca. 100 Sentinelpraxen der AGI ein Patient beprobt wird, der sich mit SARS-CoV-2 infiziert hat. Nur in der Hochphase von COVID-19 im März und April gab es in diesem Rahmen einige wenige Patienten, in deren Atemwegsprobe mit SARS-CoV-2 nachgewiesen werden konnte.

Mit einer weiteren Verbreitung von SARS-CoV-2 in der Bevölkerung steigt auch die Wahrscheinlichkeit, dass SARS-CoV-2 wieder in einer Patientenprobe aus einer der AGI-Sentinelpraxen nachgewiesen wird. (Quelle: www.rki.de/SharedDocs)

Jetzt haben wir ja wieder Werte wie in März und April, also habe ich da mal ans RKI geschrieben, ob denn da schon was gesichtet wurde, dies ist die Antwort:

vielen Dank für Ihre Anfrage. Entsprechende Virus-Nachweise werden in den Wochenberichten kommuniziert, siehe https://influenza.rki.de zu 2) die Zahl sollte konstant bleiben oder leicht steigen.

Tja, im Wochenbericht steht aber nix.  „2)“ war die Frage, ob geplant ist dieses sinnvolle Netz an Arztpraxen ein bisschen auszubauen, weil 100 sind ja dann doch nicht gerade viele.

Fazit

Infektionszahlen wie in KW 16 und keine positiven Sentinelproben. Wenn die Zahlen weiter steigen, aber die Proben weiter negativ bleiben, hatten die 300 Arztpraxenpatienten von denen die Proben stammen entweder sehr viel Glück, oder die Frage „Was messen wir da eigentlich?“ müßte mal genau nachgegangen werden.

Es darf angenommen werden, daß derzeit das Dunkelfeld, also diejenigen, die nicht an dem Virus erkranken, ausgeleuchtet wird, weil irgendwen müssen die 1.2 Millionen Tests pro Woche ja prüfen.

„The Walking Dead“

Jetzt heißt der Beitrag ja nicht umsonst „The Walking Dead“, denn die sind es, die uns bei den Zahlen fehlen. In KW 16 war der Peak mit ~266 Toten am Tag und das bei ~2.500 Neuinfizierten am Tag. Seit Wochen haben wir tausende von Neuinfizierten am Tag, aber praktisch keine Toten. Ich hatte ja in einer Hochrechnung vorgerechnet, daß uns noch ~7.600 Tote für diese „Grippe“-Welle fehlen. So gesehen, wandeln die Toten tatsächlich noch unter uns und sind dabei äußerst erfreut darüber.

Frankreich

Frankreich vermeldet ja derzeit eine massive Welle an Neuinfizierten. Was euch allerdings eher nicht bekannt sein wird, ist der Umstand, daß in Frankreich, im Gegensatz zu Spanien, derzeit weniger Menschen sterben als im Schnitt der letzten Jahre:

(C) EuroMOMO.eu ( rosa/orange Wochen sind noch nicht endgültig )

Spanien hat es echt schlimm erwischt und die bekommen das gar nicht in den Griff. Ein Mangel an Sonneneinstrahlung kann man da auch nicht als Entschuldigung gelten lassen ( Stichwort Vitamin D ), also was zum Geier machen die da falsch?

Die Franzosen haben damit scheinbar das gleiche Phänomen am Laufen, wie wir: Rudelweise Neuinfizierte, keine Toten. Also auch gilt:

OpenSSH: neuere ssh Versionen verweigern Verbindung

Posted on by

In der Fedora Welt kommt seit Wechsel auf Fedora 33 zu einem Problem mit OpenSSH-Servern, wenn die noch alte Hostskeys verwenden oder man selbst zum Authentifizieren einen Key benutzen möchte, der noch SHA1 als Hashalgorithmus benutzt.

OpenSSH: neuere ssh Versionen verweigern Verbindung

Das sollte eigentlich nicht passieren, daß man mit einem Clienten nicht mehr in seinen Server kommt, aber zur Zeit häufen sich die Meldungen, daß man mit dem OpenSSH Shellclienten von Fedora 33 nicht mehr auf Server einloggen kann, wenn entweder der Server einen alten SHA1 Keys verwendet, oder der Client einen Authkey benutzt der noch SHA1 ist.

Die temporäre Abhilfe ist, dem Clienten mitzuteilen, daß er gefälligst den alten SHA1 weiter benutzen soll. Dazu ruft man ssh mit dem Argument „-oPubkeyAcceptedKeyTypes=+ssh-rsa“ auf:

ssh -oPubkeyAcceptedKeyTypes=+ssh-rsa root@servername

Auf lange Sicht muß man natürlich einen neuen Schlüssel auf den Servern und für seinen Zugang ausrollen. Dazu muß man wissen, ob man davon überhaupt betroffen ist und da sagt einem der SSH-Keygenerator:

ssh-keygen -l -f .ssh/Krypto.id_rsa
4096 SHA256:ehMkPi1CRDPCoOYMxdTI8BB2+TkCa13CyMQXX5EXesg id@braunschweig.de (RSA)

Zuerst die Schlüssellänge 4096 Bits, dann der gesuchte Hashalgorithmus „SHA256“ und am Ende der Type „RSA“.  Wenn Ihr betroffen seid, weil Eurer Key unter 2048 und/oder SHA1 ist, dann braucht Ihr einen neuen Key:

ssh-keygen -b 4096 -t rsa-sha2-512 -N „PASSWORD“ -f „FILENAME“ -C „Kommentar“

wobei -N -f und -C alle optional sind, aber falls Ihr größere Mengen an Schlüsseln erzeugen müßte, ist das ganz hilfreich 🙂

Am Ende stellt sich nun aber heraus, daß es gar kein Fedora33 „Feature“ war, daß zu dem Problem geführt hat, sondern ein OpenSSH Bug. Hier der Patch, falls Ihr das adaptieren müßt:

— sshconnect2.c.orig 2020-09-26 07:26:37.618010545 -0700
+++ sshconnect2.c 2020-09-26 07:25:35.665009029 -0700
@@ -1281,10 +1284,9 @@
*/
if (ssh == NULL || ssh->kex->server_sig_algs == NULL ||
(key->type != KEY_RSA && key->type != KEY_RSA_CERT) ||
– (key->type == KEY_RSA_CERT && (datafellows & SSH_BUG_SIGTYPE))) {
– /* Filter base key signature alg against our configuration */
– return match_list(sshkey_ssh_name(key),
– options.pubkey_key_types, NULL);
+ ((key->type == KEY_RSA || key->type == KEY_RSA_CERT)
+ && (datafellows & SSH_BUG_SIGTYPE))) {
+ return xstrdup(sshkey_ssh_name(key));
}

/*

Der Patch ist nicht von mir, sondern von Gordon Messmer und wurde erst vor einigen Stunden bei OpenSSH eingereicht. Mal sehen was daraus wird 😉

Tödliche Lakritzvergiftung

Es gibt echt nicht, was es nicht gibt: In Massachusetts ist eine 54 jähriger Bauarbeiter nach dem Verzehr von Unmengen an Lakritze gestorben. In Lakritze ist ein Gift enthalten:

„Glycyrrhizin oder Glycyrrhizinsäure ist ein Saponin und Triterpenoid, das natürlicherweise in der Wurzel der Süßholzpflanze (Glycyrrhiza glabra) vorkommt. Das Glycosid, das zur Herstellung von Lakritz verwendet wird, ist aber auch in anderen Pflanzen wie der Frucht des Grapefruitbaums enthalten.“ (Quelle: wikipedia.org )

Wenn man davon zu viel isst, kommt es zu einem Potassiummangel im Blut ( für diesen Stoff sind Bananen als Quelle bekannt ) und in Folge zu einem Herzversagen. Also Verstand einschalten, wenn man einen Lakritzberg sieht!

Quelle: https://arstechnica.com/?p=1709881