02La prise en charge d’ARM progresse grâce à l’intégration à l’exécution et aux vérifications d’installation
ryanrhughes a ouvert la proposition de prise en charge à l’exécution de NVIDIA N1x et celle d’un ISO aarch64 le 10 octobre. Toutes deux ont ensuite été fusionnées dans quattro le 15 octobre, hors de la période couverte par ce numéro : omacom/omarchy#14820 et omacom/omarchy-iso#251. Leurs descriptions actuelles couvrent une prise en charge plus large de N1x, Snapdragon et GB10 ; ces descriptions ultérieures ne doivent pas être interprétées comme le périmètre d'origine au jour de leur ouverture.
Le 10 octobre, le commit de convergence Mac de 
omarchybot a également rejoint quattro, avec une configuration adaptée à la plateforme et une intégration au cycle de démarrage. omacom/omarchy@e1b0e5e9bb72 consigne cette intégration. Des commits distincts pour l’ISO, attribués à Emir Beganovic et comptant 
emirb parmi les participants enregistrés, ont ajouté des vérifications d'installation et de démarrage sans intervention pour la variante générique aarch64. Ils ont aussi remplacé la compression de la racine du système live par lz4, car le noyau générique ne pouvait pas lire les systèmes squashfs compressés avec zstd.
ryanrhughes a également ajouté un commit qui installe le trousseau de clés Arch Linux ARM sur le système cible et l’utilise pour vérifier les signatures. Cela corrige le rejet des paquets signés par les systèmes installés lors de leur première opération en ligne sur les paquets. omacom/omarchy-iso@2487d3b1cb7e consigne la correction ; ces commits et ces fusions dans les branches de développement ne constituent pas une version stable pour ARM.
04Un blocage empêchant l’autorisation des périphériques accompagne une proposition de retour en arrière
gavrix a signalé qu’USBGuard bloquait à la fois le clavier et la souris raccordés à un moniteur Dell utilisé comme KVM, ne laissant aucun moyen de saisie fonctionnel pour les autoriser. Selon ce témoignage, il a fallu démarrer sur un instantané pour désactiver USBGuard. omacom/omarchy#11874:issuecomment-6102552400 documente les conséquences pour l’utilisateur.
omarchybot a ouvert omacom/omarchy#14938 en fin de journée le 10 octobre pour revenir sur les mécanismes d’autorisation USB et Thunderbolt. La description actuelle comprend des travaux de migration pour supprimer les contrôles déjà installés et les restrictions au démarrage, car retirer uniquement le code source laisserait la protection active sans les commandes permettant d'autoriser les périphériques. Le rapport de validation publié le même jour par omarchybot décrivait des vérifications dans des environnements de travail jetables, tout en précisant que la restauration du micrologiciel Thunderbolt sur du matériel physique n’avait pas été testée.
La proposition de retour en arrière a été fermée sans fusion le 12 octobre, hors de la période couverte. Son état actuel ne permet donc pas d’établir que la suppression proposée a rejoint quattro.
06La proposition d’installation réseau sur petite clé USB est fermée en raison du coût de maintenance
Dans omacom/omarchy-iso#256, 
Tsurgcom a proposé un support d’installation réseau assez petit pour tenir sur une clé USB d’une capacité nominale de 4 Go. En supprimant le miroir de paquets inclus, l’auteur a indiqué avoir obtenu une image d’environ 1.41 Gio, au prix de l’abandon de l’installation hors ligne et de la nécessité d’une connexion Internet fonctionnelle.
Les essais en conditions réelles ont révélé des défauts dans l’initialisation du trousseau de clés et l’analyse des résultats de recherche Wi-Fi. Tsurgcom a indiqué les avoir corrigés, puis avoir retiré les sockets d’agents inclus par erreur dans les données d’initialisation du trousseau. Selon le rapport de test de l'auteur dans omacom/omarchy-iso#256:issuecomment-6101577594, une image reconstruite a ensuite mené à bien une installation réseau sans intervention, puis un redémarrage, sans aucune unité en échec.
dhh a refusé d’ajouter un autre mode d’installation en raison de la charge de maintenance existante des ISO, tout en laissant la possibilité d’une maintenance indépendante. La proposition a été fermée sans fusion le 10 octobre. omacom/omarchy-iso#256:issuecomment-6103168854 consigne cette décision.
07Piphone rejoint le catalogue après des corrections sur l’accès au téléphone et le périmètre des applications autorisées
Piphone, proposé par 
areu01or00, permet de contrôler un iPhone depuis un widget et un panneau Omarchy, en s’appuyant sur WebDriverAgent et une extension Pi. 
github-actions[bot] a annoncé sa publication dans le catalogue sous la forme d’un instantané vérifié, après examen par un responsable de maintenance. omacom/omarchy-plugin-marketplace#10915:issuecomment-6098503193 consigne cette publication.
La revue de 
HANCORE-linux a relevé un accès local sans authentification aux points d’accès de contrôle du téléphone, ainsi qu’une exposition de profils privés. areu01or00 a remplacé les points d’accès directs par des sockets Unix accessibles uniquement à leur propriétaire, renforcé la gestion des profils et isolé le tunnel sous-jacent dans un espace de noms réseau privé. Des corrections ultérieures ont ajouté une vérification de l’application effectivement au premier plan avant les actions, puis une nouvelle vérification après l’envoi de l'approbation, et ont arrêté les processus de surveillance lorsque leur application sortait du périmètre autorisé.
HANCORE-linux a accepté les corrections examinées concernant les points d’accès, les profils, le tunnel et le périmètre des applications, tout en exigeant une configuration manuelle pour la compilation locale, WebDriverAgent signé et les réglages de Pi et du modèle. omacom/omarchy-plugin-marketplace#10915:issuecomment-6098467632 consigne cette décision. La vérification du catalogue porte sur l’instantané examiné et ne constitue pas un audit de sécurité.
08La vérification d’Omabump révèle une faille dans un hook privilégié de mise à niveau de Voxtype
La demande de 
Vladkarok visant à vérifier un instantané plus récent d’Omabump reste ouverte dans omacom/omarchy-plugin-marketplace#10910. Lors de la revue, HANCORE-linux a repéré un hook du paquet Voxtype qui lisait un fichier de transfert dans un répertoire temporaire partagé sans en vérifier le propriétaire, et acceptait comme lanceur système un exécutable contrôlé par un attaquant. Il s'agissait du mécanisme mis en cause.
Vladkarok a confirmé le mécanisme et expliqué que le même hook s’exécutait lors des mises à niveau ordinaires des paquets : la correction devait donc porter sur le paquet plutôt que sur le plugin. L’auteur a décrit une modification proposée reposant sur un stockage réservé à root et sur des restrictions des chemins d’exécutables restaurés, puis prévu de mettre à jour la recette épinglée d'Omabump une fois ce correctif fusionné. omacom/omarchy-plugin-marketplace#10910:issuecomment-6098036843 consigne cette réponse ; la discussion fournie ne permet pas d’établir que la correction du paquet a été menée à terme.
09La revue de Ward soulève le risque de divulgation lié aux autorisations de lecture seule sur des répertoires
La proposition Ward de 
jacob-vincent-mink reste ouverte sous la référence omacom/omarchy#10974. Sa description actuelle propose des processus Quickshell tiers isolés, assortis d’approbations propres à chaque révision et d'autorisations ciblées, tout en indiquant que le conditionnement en paquets natifs, le routage via le registre et les travaux plus larges de validation restent inachevés.
Le 10 octobre, 
SorenHJohansen a signalé lors de sa revue que des autorisations de lecture seule pouvaient exposer la configuration protégée de l’hôte, même lorsque les autorisations d’écriture étaient refusées. La revue décrivait une reproduction de bout en bout du processus d’approbation et demandait soit de rejeter ces répertoires racines pour les deux modes d’accès, soit de définir explicitement les informations dont la divulgation était autorisée. Elle soulevait aussi des problèmes de chemin du compilateur et d'environnement graphique dans des tests facultatifs. omacom/omarchy#10974:issuecomment-6102074229 ajoute ainsi une question concrète de confidentialité à cette proposition d’isolation toujours ouverte.
