KDE Connect, Fedora und Android 4+

„Das Gerät kenne ich nicht!“ meinte KDE-Connect nach dem Update von Fedora 32 auf Fedora 33. Glatt gelogen.

KDE Connect, Fedora und Android 4+

Wer KDE-Connect auf einem älteren Android fährt, wird mit Fedora 33+ einen Schock erleiden, weil sich Desktop und Telefon nicht mehr sehen können. Wenn man der Sache mit Hilfe von TCPDUMP nachsteigt, dann sieht man eine 1a Kommunikation, wenn eins der beiden Geräte die Suche startet. Das macht es nicht gerade einfacher 😉

Mit Fedora 33 wurde u.a. SHA1 aus der Security-Policy gestrichen, weil total veraltet. Leider kann so ein älteres Android kein SHA256 und da ist die Geschichte schon zu Ende, oder doch nicht?

Ein Update von KDE-Connect auf 1.17 bringt jedenfalls keine Lösung, da auch diese Version die Android Build-in Cryptoroutinen benutzt. Vielleicht kann man ja auf der Fedoraseite was drehen? Und Ja, man kann:

sudo update-crypto-policies –set DEFAULT:FEDORA32
killall kdeconnectd

Fertig. Jetzt noch die Ansprache: „Für etwaige Hacks von Ihrem PC durch das Reduzieren der Sicherheitsanforderungen sind Sie selbst verantwortlich.

Gnome 3.38: fühlt sich wie ein Rückschritt an

Fedora 33 BETA im Test und es ist nicht so wies sein sollte.

Gnome 3.38: fühlt sich wie ein Rückschritt an

Diverse Probleme plagen Fedora 33 in meinem jüngsten Test. Als Testhardware habe ich mal mein Surface Pro 4 benutzt, was ich besser gelassen hätte, denn Fedora 33 bootet nicht vom USB Stick, oder doch? Mögliche Antworten: Ja / Nein / Vielleicht   und alle sind korrekt :(((

Über das letzte Wochenende habe ich mir mit dem Jungs von der Fedora-Mailingliste einen Debugmarathon gegönnt, nur leider komplett erfolglos.

Steckt man den USB Stick mit Fedora 31 ins Laufwerk, ist ein Booten problemlos möglich, egal wie und wann man den Stick reinsteckt. Mit Fedora 33 geht das nicht mehr. Steckt man den Stick rein, startet die Hardware, wechselt ins Bios und bootet dann von USB, gibt es nur einen Reset. Steck man den Stick erst ein, wenn man schon im Bios ist, dann geht’s 😐  Das macht natürlich wenig Hoffnung, wenn das Gerät bald aktualisiert werden muß.

Wir haben den Grubbootloader ersetzt, die Biosbootconfig in 3 Sekunden zerstört, in 3h wiederhergestellt, und am Bootverhalten vom Surface änderte sich bezüglich Fedora 33 nichts. Es geht einfach nicht und Debuggen geht auch nicht, weil was willste da debuggen, wenn das System einen Instantreset macht? Wir tippen auf Firmwarefehler im EFI Bios des Surface, aber da kein Windows mehr drauf ist, wo sollte das Update dafür herkommen?

Aber, ich habe ne Menge über die Grubkonsole gelernt! Auch das die Anleitung von Fedora zum Recovery nicht funktionieren 🙁

Wenn es denn bootet..

… kommt man zum neuen Gnome 3.38 Desktop. Ich konnte zwar die neuen Monitoranordnung nicht testen, aber ansonsten ist es fast unverändert. Was einen Tabletbenutzer so richtig nerven wird, ist das neue Ausklappmenü zum Abmelden und Abschalten des Rechners.

Was für ein SCHEISS! Sind wir ernsthaft wieder in den Neunziger Jahren angekommen?

Was soll sowas?  Hat wirklich jemand unabsichtlich auf „Bereitschaft“ gedrückt oder versehentlich das Neustarticon nicht gefunden?

Ich glaube kaum, also warum in zum Geier ändert man das von ONE-Click in ein CLICK-MOVE-CLICK System????

Es war doch schon perfekt 🙁

Probleme mit Videokonferenzen

Was jetzt kommt ist eine alter Hut: Wayland ist noch nicht fertig! Party ! Jubbel ! Heiterkeit !  … moment.. nicht fertig? Aber es geht doch!?!?  Nein, tut es doch nicht..  Screenrecording geht nicht:

Wie man in diesem Screenshot sehen kann, sieht man nicht außer einem schwarzen Bildschirm, obwohl Firefox ( siehe oben ) den Bildschirm teilt. Wenn man das nicht in einer VM ( Screenshot ) sondern auf einer HW ( Surface Pro ) macht, dann ist auch das Jitsi Meet Icon links unten in der Ecke passend markiert, weil er wirklich Schwarzbilder streamt. Einfach selbst testen.

Das nächste Desaster naht

Wenn man jetzt LUG Mitgliedern die neuen Sachen wie ZRAM, BttrFS  zeigen will, geht das nicht, also muß man kreativ werden:

Überlegung: Installiere XRDP, lege User an, Verbinde Dich mit User auf RDP  und zeige Ihm einfach alles, indem Du von Deinem Desktop z.b. xFreeRDP oder Remmina überträgst … Tja.. was soll ich sagen.. wie wärs mit „Ein Bild sagt mehr als tausend Worte“ …

Und dann steht Ihr da mit Eurem RDP Desktop der NUR NOCH diese Abfrage anzeigt, die man zwar beenden kann, die dann aber in der nächsten ms wieder aufpoppt!

Abrechen => Endlosslooping

Anmelden => neuer Requester mit anderem Text, aber den gleichen zwei Buttons!

Keine Eingabemöglichkeit!

Wie soll man da ein Passwort für einen User eingeben, der gar kein Passwort hat ????

Aus der Nummer kommt man nicht mehr raus, ergo muß man die RDP Session beenden und ALLE PROZESSE des eingeloggten Benutzers als Rootuser KILLEN. Das errinnert mich stark an ein Scherzprogramm aus den 90zigern.. hmm, wieder die 90ziger.. ein Muster deutet sich an 😉

Natürlich gibt es eine Ursache und eine Lösung, aber die Situation sollte gar nicht erst auftreten.

Ursache: pcsc-lite und Konsorten! Ein SmartCard-Service … auf einem Gerät ohne einen SmartCardreader!

Wie dämlich ist das, daß der sich dann auch noch so startet, obwohl er mit nichts arbeiten kann?

Schritt 1 eines SmartCardDaemons wäre festzustellen, welchen SmartCardreader er benutzen soll.
Schritt 2 eine Fehlermeldung ausgeben, weil er keinen gefunden hat.

Aber sicher nicht in einer Endlosschleife ohne Abbruchbedingung sinnlos Leute ärgern, seit JAHREN SCHON!

Lösung

Falls Euch das mal betreffen sollte, denn ich habe so meine Zweifel, daß andere Distris da besser abschneiden:

systemctl stop pcscd;systemctl disable pcscd
killall -9 pcscd
dnf erase pcsc* -y

und weg damit. Viel Spaß, falls Ihr RDP und SmartCards zusammen benutzen müßt. Schreibt mal eine Karte, wenn Ihr den Ort gefunden habt, wo das zusammen funktioniert 😉

Mal sehen was die Jungs von der Liste dazu sagen, weil die User-Experience, die ja so wichtig ist, mal direkt lang auf die Nase gefallen ist.

ZRAM

ZRAM läuft.. aber irgendwie merkt man nichts.. 2 GB RAM sind 2 GB RAM. Tja.. da braucht es wohl erst einmal mehr um überhaupt damit arbeiten zu können.

Bttrfs habe ich nicht ausprobiert, ich habe ja schon funktionierende Festplatten mit einem OS drauf 😉

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

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: