Einheitliche Eingabesteuerung, Fortschritte bei der ARM-Installation und Sicherheitskorrekturen für Plugins

01Tastaturlayouts und Eingabe-Engines lassen sich gemeinsam steuern

dhh führte omacom/omarchy#14433 am 10. Oktober in quattro zusammen. Die übernommene Änderung verknüpft die Tastaturauswahl im Installationsprogramm mit der Einrichtung der Eingabe-Engines und ermöglicht die sofortige Auswahl von Tastaturlayout und Eingabemethode über das Menü „Typing“. Super+I schaltet gemeinsam durch Layouts und Engines zur Zeichenkomposition, Super+Shift+I in umgekehrter Richtung. Diese Änderungen betreffen den Entwicklungszweig.

Bei der Prüfung durch greptile-apps[bot] fiel auf, dass die per Tastenkürzel getroffene Auswahl verloren ging, wenn kein Textfeld den Fokus hatte. Außerdem führten Fehler beim Schreiben von Schriftdateien dazu, dass gespeicherte Eingabemethoden nicht mehr mit den Markierungen im Menü übereinstimmten. dhh berichtete von Korrekturen, die die Auswahl auch ohne fokussiertes Textfeld beibehalten und nach einem Fehler beim Schreiben einer Schriftdatei die vorherige Eingabegruppe wiederherstellen. omacom/omarchy#14433:discussion_r4237897756 und omacom/omarchy#14433:discussion_r4239436913 dokumentieren diese Korrekturen.

xdanger schlug vor, die chinesische Eingabe mit der Umschalttaste zu verlassen und ein ähnliches Verhalten für japanische und koreanische Eingabe-Engines vorzusehen. dhh sagte zu, Caps Lock und das Verhalten der Umschalttaste in einer Folgeänderung anzugehen. Dieser Vorschlag blieb damit von den bereits übernommenen Änderungen an der Texteingabe getrennt. omacom/omarchy#14433:issuecomment-6098200521 und omacom/omarchy#14433:issuecomment-6098373295 dokumentieren den Vorschlag und die Antwort.

02ARM-Unterstützung kommt durch Laufzeitintegration und Installationsprüfungen voran

ryanrhughes reichte am 10. Oktober den Vorschlag zur NVIDIA-N1x-Laufzeitunterstützung und den Vorschlag für ein aarch64-ISO ein. Beide wurden später, am 15. Oktober und damit außerhalb des Berichtszeitraums dieser Ausgabe, in quattro übernommen: omacom/omarchy#14820 und omacom/omarchy-iso#251. Ihre aktuellen Beschreibungen umfassen eine breitere Unterstützung für N1x, Snapdragon und GB10. Diese späteren Beschreibungen dürfen nicht als ursprünglicher Umfang zum Zeitpunkt der Einreichung verstanden werden.

Am 10. Oktober gelangte auch der Commit von omarchybot zur Mac-Konvergenz in quattro. Er führte eine plattformabhängige Einrichtung und die Integration in den Boot-Lebenszyklus ein. omacom/omarchy@e1b0e5e9bb72 dokumentiert diese Integration. Separate ISO-Commits, die Emir Beganovic zugeschrieben werden und bei denen emirb zu den verzeichneten Beteiligten zählt, ergänzten die unbeaufsichtigte generische aarch64-Installation und Boot-Prüfungen. Außerdem stellten sie die Komprimierung des Live-Root-Dateisystems auf lz4 um, da der generische Kernel kein zstd-komprimiertes SquashFS lesen konnte.

ryanrhughes ergänzte außerdem per Commit die Installation des Arch-Linux-ARM-Schlüsselbunds auf dem Zielsystem und die Signaturprüfung anhand dieses Schlüsselbunds. Damit wird das Problem behoben, dass installierte Systeme beim ersten Online-Paketvorgang signierte Pakete ablehnen. omacom/omarchy-iso@2487d3b1cb7e dokumentiert die Korrektur. Diese Commits und Übernahmen in Entwicklungsbranches belegen jedoch keine stabile ARM-Veröffentlichung.

03Workarounds in Paket und Shell beheben Plugin-Probleme mit Qt 6.12

outfoxxed schlug einen vorläufigen Quickshell-Patch für einen Konflikt bei Typnamen in Qt 6.12 vor, der Plugins beeinträchtigte. ryanrhughes übernahm ihn in den master-Branch des Paket-Repositorys. Anschließend meldete github-actions[bot], dass quickshell 0.3.2-3 auf edge sowohl für x86_64 als auch für aarch64 verfügbar sei. omacom/omarchy-pkgs#935 und omacom/omarchy-pkgs#935:issuecomment-6096470146 belegen die Übernahme und Veröffentlichung.

outfoxxed übernahm über omacom/omarchy#14845 auch die zugehörige Shell-Änderung in quattro. Die eingecheckte Änderung aktiviert den Workaround für QtQuick-Importe und umgeht den Namenskonflikt beim Typ Color, indem sie Importe der Version 6.11 verwendet. Hier kommen eine Paketveröffentlichung auf edge und eine Shell-Änderung im Entwicklungsbranch zusammen.

04Bericht über Eingabesperre bei Zubehörfreigabe begleitet Rücknahmevorschlag

gavrix berichtete, dass USBGuard sowohl die Tastatur als auch die Maus über einen als KVM genutzten Dell-Monitor blockierte. Damit blieb kein funktionierendes Eingabegerät übrig, um sie freizugeben. Laut Bericht musste zur Wiederherstellung ein Snapshot gebootet werden, um USBGuard zu deaktivieren. omacom/omarchy#11874:issuecomment-6102552400 dokumentiert die Auswirkungen für den Nutzer.

omarchybot eröffnete am späten 10. Oktober omacom/omarchy#14938, um die USB- und Thunderbolt-Autorisierung zurückzunehmen. Die aktuelle Beschreibung umfasst Migrationsarbeiten, die bereits installierte Durchsetzungsmechanismen und Boot-Beschränkungen rückgängig machen sollen. Würde nur der Quellcode entfernt, bliebe der Schutz ohne seine Freigabesteuerung aktiv. Der noch am selben Tag veröffentlichte Validierungsbericht von omarchybot beschrieb Prüfungen mit kurzlebigen Test-Workern und hielt ausdrücklich fest, dass die Wiederherstellung der physischen Thunderbolt-Firmware nicht getestet worden war.

Der Rücknahmevorschlag wurde am 12. Oktober und damit außerhalb des Berichtszeitraums ohne Übernahme geschlossen. Sein aktueller Status belegt daher nicht, dass die vorgeschlagene Entfernung in quattro gelangt ist.

05Veralteter Sperrstatus kann erneute Bildschirmsperren verhindern

Das derzeit offene Issue omacom/omarchy#14816 wurde am 10. Oktober von dsundt eröffnet. In einem Nachtrag noch am selben Tag berichtete dsundt, dass die Shell auf dem getesteten Rechner nach jedem erfolgreichen Entsperren weiterhin von einem gesperrten Zustand ausging. Die nächste Sperranforderung blieb dadurch wirkungslos. Als Workaround wurde ein Neustart der Shell genannt. omacom/omarchy#14816:issuecomment-6100203282 hält diese Beobachtung unabhängig von späteren Änderungen an der Issue-Beschreibung fest.

scottadair meldete denselben Zustand auf einem weiteren Laptop: zweimaliges Suspendieren durch Zuklappen ohne sichere Sperre sowie eine nicht funktionierende manuelle Sperre. rafalyovson brachte den Bericht mit einer bestehenden Quickshell-Untersuchung und konkurrierenden Lösungsansätzen in Verbindung und berichtete zugleich, das Problem auf dem zuletzt getesteten edge-Build reproduziert zu haben. Dabei handelt es sich um Berichte und Diagnosen von Mitwirkenden, nicht um einen Beleg für eine bereits übernommene Korrektur. omacom/omarchy#14816:issuecomment-6097484047 und omacom/omarchy#14816:issuecomment-6099485761 dokumentieren den Verlauf.

06Vorschlag für kleines USB-Netinstall-Medium wegen Wartungsaufwand geschlossen

Tsurgcom schlug in omacom/omarchy-iso#256 ein Netzwerkinstallationsmedium vor, das auf einen USB-Stick mit nominell 4 GB passt. Nach Angaben des Autors entstand durch Weglassen des mitgelieferten Paketspiegels ein rund 1.41 GiB großes Abbild. Dafür entfällt die Offline-Installation und eine funktionierende Internetverbindung wird benötigt.

Tests im Live-System deckten Fehler bei der Vorbelegung des Schlüsselbunds und beim Auswerten von WLAN-Scans auf. Tsurgcom berichtete, diese behoben und anschließend auch Agent-Sockets entfernt zu haben, die versehentlich in die Schlüsselbund-Vorlage geraten waren. Laut Testbericht des Autors in omacom/omarchy-iso#256:issuecomment-6101577594 absolvierte ein neu erstelltes Abbild danach eine unbeaufsichtigte Netzwerkinstallation samt Neustart, ohne dass Units fehlschlugen.

dhh lehnte einen weiteren Installationsmodus wegen des bereits bestehenden Wartungsaufwands für das ISO ab, ließ aber Raum für eine unabhängige Pflege. Der Vorschlag wurde am 10. Oktober ohne Übernahme geschlossen. omacom/omarchy-iso#256:issuecomment-6103168854 dokumentiert die Entscheidung.

07Piphone nach Korrekturen an Telefonzugriff und App-Grenzen im Marketplace gelistet

Das von areu01or00 eingereichte Piphone ermöglicht die Steuerung eines iPhones über ein Omarchy-Widget und ein Panel, unterstützt durch WebDriverAgent und eine Pi-Erweiterung. github-actions[bot] meldete nach der Prüfung durch den Maintainer die Veröffentlichung als verifizierten Marketplace-Snapshot. omacom/omarchy-plugin-marketplace#10915:issuecomment-6098503193 dokumentiert die Veröffentlichung.

Bei der Prüfung stellte HANCORE-linux fest, dass lokal ohne Authentifizierung auf Endpunkte zur Telefonsteuerung zugegriffen werden konnte und private Profildaten offengelegt wurden. areu01or00 ersetzte die direkten Endpunkte durch Unix-Sockets, auf die nur der Eigentümer zugreifen kann, verschärfte die Profilverarbeitung und isolierte den zugrunde liegenden Tunnel in einem privaten Netzwerk-Namensraum. Weitere Korrekturen prüften vor Aktionen die tatsächlich im Vordergrund laufende App, wiederholten die Prüfung nach dem Übermitteln der Freigabe und stoppten Beobachter, sobald ihre App den erlaubten Geltungsbereich verließ.

HANCORE-linux akzeptierte die geprüften Korrekturen an Endpunkten, Profilen, Tunnel und App-Grenzen, verlangte jedoch weiterhin eine manuelle Einrichtung des lokalen Builds, des signierten WebDriverAgent und der Pi-/Modellkonfiguration. omacom/omarchy-plugin-marketplace#10915:issuecomment-6098467632 dokumentiert diese Entscheidung. Die Marketplace-Verifizierung gilt für den geprüften Snapshot und ist kein Sicherheitsaudit.

08Omabump-Verifizierung deckt Schwachstelle in privilegiertem Voxtype-Upgrade-Hook auf

Der Antrag von Vladkarok, einen neueren Omabump-Snapshot zu verifizieren, ist in omacom/omarchy-plugin-marketplace#10910 weiterhin offen. Bei der Prüfung entdeckte HANCORE-linux einen Voxtype-Paket-Hook, der eine Übergabedatei aus einem gemeinsam genutzten temporären Verzeichnis las, ohne deren Eigentümer zu prüfen, und eine von Angreifern kontrollierte ausführbare Datei als systemweiten Launcher akzeptierte.

Vladkarok bestätigte den Mechanismus und erklärte, dass derselbe Hook auch bei gewöhnlichen Paket-Upgrades ausgeführt werde. Die Korrektur gehöre daher in das Paket und nicht in das Plugin. Der Autor beschrieb eine vorgeschlagene Änderung, die ausschließlich für root zugänglichen Speicher nutzt und die Pfade wiederhergestellter ausführbarer Dateien einschränkt. Nach Übernahme dieser Korrektur sollte das in Omabump festgeschriebene Build-Rezept aktualisiert werden. omacom/omarchy-plugin-marketplace#10910:issuecomment-6098036843 dokumentiert die Antwort; die vorliegende Diskussion belegt keinen Abschluss der Paketkorrektur.

09Ward-Review hinterfragt Datenoffenlegung durch schreibgeschützte Verzeichnisfreigaben

Der Ward-Vorschlag von jacob-vincent-mink ist unter omacom/omarchy#10974 weiterhin offen. Die aktuelle Beschreibung sieht isolierte Quickshell-Worker von Drittanbietern mit revisionsgebundenen Freigaben und ausgewählten Zugriffsrechten vor. Zugleich nennt sie native Paketierung, Registry-Routing und weitergehende Abnahmearbeiten als noch nicht abgeschlossen.

Am 10. Oktober berichtete Reviewer SorenHJohansen, dass reine Lesefreigaben geschützte Host-Konfiguration offenlegen könnten, selbst wenn Schreibfreigaben abgelehnt würden. Der Reviewer beschrieb eine Reproduktion des vollständigen Freigabeablaufs und verlangte, die betreffenden Verzeichniswurzeln entweder für beide Zugriffsarten abzulehnen oder die Offenlegung ausdrücklich zu regeln. Dieselbe Prüfung sprach außerdem Probleme mit Compiler-Pfaden und der Grafikumgebung in optionalen Tests an. omacom/omarchy#10974:issuecomment-6102074229 ergänzt den weiterhin offenen Isolationsvorschlag um eine konkrete Frage zur Vertraulichkeit.