Pinephone: kleines Fedora Statusupdate

Weil mein Android J3 wohl einen defekten Kondensator im Empfangsschwingkreis hat, kommt Ihr jetzt in den Genuss eines Pinephone Statusreports 🙂

Pinephone: kleines Fedora Statusupdate

Fangen wir mal damit an:

Wenn Eurer Telefon den Funkmast mal findet und meisten gar nichts mehr finden will, dann ist entweder der Standort gut abgeschirmt, oder der EmpfĂ€nger im Modem des Handies defekt. So oder so, reparieren lohnt nicht, auch wenn das Ersatzteil nur wenige Cents kosten wĂŒrde, weil man den (wahrscheinlich) defekten SMD Kondensator erst aufwendig finden muß. Da sind die Lohnkosten leider zu hoch fĂŒr 🙁

Gut, wenn man ein voll installiertes und konfiguriertes Pinephone rumliegen hat. Erstens kann man damit leicht testen, ob der Funkmast defekt ist, oder der EmpfĂ€nger hin ist. Weniger gut ist, wenn Deine Pinephone DE in eine Endlosschleife wechselt, sobald Du mal rumswipst 🙁

Phosh 0.20.0

Phosh 0.20.0 hat einen, zum GlĂŒck behebbaren Bug, daß es in genauso eine Endlosschleife geht, wenn man den Taskmanager zweimal aufrufen will. Das Toppanel bekommen man zwar noch runter geswiped, aber rauf geht nichts mehr und Sound + Volumetasten waren auch nicht mehr reaktiv.

Um rauszufinden, ob Ihr den Fehler selbst beheben könnt, gebt mal als Pineuser per SSH ein:

$ gsettings get org.gnome.desktop.interface enable-animations

Wenn da „false“ rauskommt, dann seid Ihr mit dem Fix hier:

$ gsettings set org.gnome.desktop.interface enable-animations true
$ systemctl restart phosh

schnell auf der Gewinnerseite 😉

Pinephone powered down

NatĂŒrlich war die Zeit, als der Bug bei mir aktiv war nicht ganz ohne positiven Nebeneffekt, weil wir gleich das nĂ€chste Problem identifizieren konnten:

Wenn phosh oder phoc in so einer Endlosschleife festhĂ€ngen, können Sie auf Tastenevents nicht mehr reagieren. Da greift dann der systemd-logind ein und behandelt das Event so, wie es in /etc/systemd/logind.conf festgelegt ist. DrĂŒckt man in so einer Situation auf die Powertaste, denn fĂ€hrt der logind das System einfach runter! Das will man natĂŒrlich nicht, sondern Systemd soll Phosh neustarten, damit das wieder reagiert.

Das erreichen wir so:

Wir legen eine Datei namens /etc/systemd/logind.conf.d/ignore-power-key.conf an und schreiben da rein:

[Login]
HandlePowerKey=ignore

Dann..

$ systemctl restart systemd-logind phosh

und das Problem sollte weg sein. Da wir das erst heute zusammen mit Purism rausgefunden haben, muß ich noch abwarten wie sich das konkret auswirkt. Da aber min. eine andere Distro das auch schon per Default so blockiert, wird es wohl gehen.

Der aktuelle Stromverbrauch

Heute Nacht bin ich bei ca. 8h DeepSleep des Handies auf folgende Batterydauer bis zum Aufladen gekommen:

4% battery ( 84%->80%) in 8h im DeepSleep

ergibt 12% pro Tag, ergibt eine Woche Deepsleep, bevor man es wieder Aufladen muß. Dabei wird das Handy nicht ganz leer, was gut fĂŒr den Akku ist. Allerdings verkĂŒrzt sich das dramatisch, wenn man es einschaltet 😀

 

Inkorrektes Portswitchen beim Telefonieren

Ihr wisst, daß es im Pinephone 2 Lautsprecher gibt, den zum Telefonieren ( internal Earpiece ) und den Lautsprecher ( Speaker ). Beim Telefonieren ist mir ausgefallen, daß der Callsd mal wieder die Profile nicht richtig schalten wĂŒrde ( Default <-> Phone ) . Dem war aber nicht so, weil bei den Ports lediglich die falschen AusgabegerĂ€te eingestellt waren. Nachdem ich das im Pulseaudio-LautstĂ€rkeregler korrekt eingestellt hatte, sprang das Pine wieder zwischen Telefonbetrieb und Lautsprecher, fĂŒr alles andere, hin und her.

„Sicherheitsproblem“ fĂŒr den Einen, „paßt schon“ fĂŒr den Anderen

Im Lockscreen von Phosh kann man ohne Authentifizierung WLAN, Bluetooth und Mobile Daten abschalten. Einer kleinen Umfrage gestern bei Linux am Dienstag, konnten wir entnehmen, daß sich die OSe dahingehen nicht ganz einige sind, ob es ein Sicherheitsproblem darstellt oder nicht. AOS 5+ ist z.b. der Meinung, daß darf man ohne Authentifizierung nicht, iOS war da anderer Meinung.

Ich denke, es ist ein Sicherheitsproblem, weil wenn ich z.b. einen Tracker installiert habe, der mein Telefon wieder finden soll, wenn es geklaut wird oder verloren geht, dann sollte der Dieb das nicht abschalten können. Ok, er könnte das Telefon komplett abschalten, aber sobald er es bootet, wĂŒrde der Tracker das melden.

Der entsprechende Bugreport bei Purism wurde nicht sofort geschlossen, was bedeutet, meine Argumente scheinen gewirkt zu haben. Der Kompromissvorschlag sieht vor, daß es „sicher“ ausgeliefert wird, aber per Control-Center in den „unsicheren“ Modus geĂ€ndert werden kann. So haben alle den Zustand, den sie möchten.

Keine CoreDumps mehr nach Update

Stand Vorgestern, 15.8.2022, stĂŒrzt Evolution beim Start nicht mehr ab, wenn man auf dem neuesten Softwarestand ist. Das Booten geht damit auch wieder deutlich schneller 😉

Verbesserungen zur Kenntnis genommen

Phosh 0.20.0, oder auch schon 0.19.x, haben im Lockscreen beim Angerufen werden eine deutliche optische Verbesserung erfahren. Das sieht richtig schick aus. Weiter so!

PVA: kleines Sicherheitsloch im IMAP Modul

Wie das so mit komplexer Software ist, CVE Meldungen sind quasi vorprogrammiert, aber einfache Programmierfehler tun es meistens auch 🙁

PVA: kleines Sicherheitsloch im IMAP Modul

Jetzt ist der Einschlagkrater durch die im PVA gefundene SicherheitslĂŒcke nicht besonders groß, man mĂŒĂŸte Ihn vermutlich mit der Lupe suchen, weil kaum wer von dem neuen Feature wußte und es ausprobiert hat, aber, zur Vermeidung gleichartiger zukĂŒnftiger UnfĂ€lle, soll die LĂŒcke seziert und dokumentiert werden.

Was ist passiert?

In der MailConnection-Komponente, die macht die IMAP Verbindung auf, war ein Programmierfehler drin, der die verschlĂŒsselte Verbindung zum IMAP Server unterband. Wer also die neue Funktion schon ausprobiert hat , muß mindestens auf diesen Commit updaten: 685ee5ecaa486006a0cee04cac763ee479160e6e

Hier der fehlerhafte Code:

Properties props = System.getProperties();
if ( m.secure == true ) {
       props.setProperty("mail.store.protocol", "imaps");
} else props.setProperty("mail.store.protocol", "imap");

Session session = Session.getInstance(props, null);
Store store = session.getStore("imap");
store.connect(m.servername, m.username, m.password);

Statt die laut Konfiguration (m.secure) gewĂŒnschte Verbindungsart „imaps“ zu wĂ€hlen, zog es der Code vor, dann doch unabhĂ€ngig davon „imap“ zu verwenden. Korrekt wĂ€re diese Zeile gewesen:

Store store = session.getStore();

Was war die Ursache?

Als Ursache konnte „mangelndes VerstĂ€ndnis“ der Methode getStore(…) ausgemacht werden, um genau zu sein, wurde erwartet, daß es sich um den Unterschied zwischen „POP3“ oder „IMAP“ handelt, weil der Sicherheitslevel wurde ja vorher schon festgelegt, aber leider ĂŒberschrieb der Aufruf diese Voreinstellung wieder.

Was mĂŒĂŸt Ihr tun?

Im Repo ist das Update bereits enthalten, so daß alle die, die Automatische Updates einspielen, schon sicher sind.
Wer seinen PVA selbst baut, der muß einmal updaten und compilieren.

Wie wurde es gefunden?

Vor 11 Jahren, ja, einfach weiterlesen, entschied ich, daß meine POP3/IMAP Serverlogs von einer Software auf genau diese unverschlĂŒsselten Verbindungen prĂŒft und den Benutzer darĂŒber informiert, daß er irgendwo eine unsichere Konfig hat. 11 Jahre lang habe ich keine Email erhalten, und jetzt rettet dieses kleine Script dem PVA den Arsch 😉

PS: Falls wer dachte, daß man im Github einfach mal so ein Security Advisory schreiben könnte, der hat das noch nie versucht und mir ist jetzt klar, warum so viele Projekte mit LĂŒcken, keine SecurityeintrĂ€ge haben 🙁

PVA: Carola hat Ihr eigenes Repo bekommen

Ein wichtiger Schritt fĂŒr unseren kleinen PVA, ein irrelevanter Schritt fĂŒr die Menschheit 😉

PVA: Carola hat Ihr eigenes Repo bekommen

So Fedora-Freunde, ihr könnt jetzt PVA direkt installieren, sofern ihr mir vertraut, versteht sich 😉

Schreibt das hier mal in /etc/yum.repos.d/pva :

[pva]
name=PVA $releasever – $basearch
baseurl=http://repo.linux-am-dienstag.de:80/$basearch/fedora/$releasever/
enabled=1
metadata_expire=1d
#repo_gpgcheck=1
type=rpm
gpgcheck=1
gpgkey=http://repo.linux-am-dienstag.de:80/RPM-GPG-KEY-fedora-$releasever-$basearch

Dann macht:

dnf –repo=pva makecache
dnf install pva-base pva-vosk-model-de-small

und der PVA samt Sprachmodell installiert sich bei Euch \o/ .

Wie tauscht Ihr das Modell aus?

Ihr besucht diese Seite https://alphacephei.com/vosk/models und ladet die passende ZIP Datei runter. Die wird dann im /usr/share/pva ausgepackt und mit

rm -f model; ln -s vosk-model-de-0.21 model

verlinkt Ihr das aktuelle Model. technisch braucht man das nicht machen, weil mit dem Small RPM kommt eine passende Konfigdatei mit, die dem PVA das alles passend erklÀren sollte.

Wenn da was nicht passen sollte, schickt mir einfach eine Email mit dem Problem zu, oder schreibt es in die Kommentare.