Nos derniers travaux sur Canaille financés par la fondation NLNet nous amènent à sortir une version bêta. Faisons le point.
Derniers travaux
Gestionnaire de tâches
Nous avons implémenté un gestionnaire de tâches qui permet à Canaille d'effectuer les tâches longues de manière asynchrone.
C'est utilisé notamment pour propager les requêtes SCIM ou les envois de mail.
L'implémentation utilise dramatiq, et nous avons publié le paquet dramatiq-eager-broker qui permet de conserver un comportement synchrone dans la suite de tests, et dans le cas où le gestionnaire de tâches ne serait pas configuré.
Certification OpenID Connect
Nous vous en parlions récemment, Canaille a obtenu au mois de septembre dernier la certification de la fondation OpenID Connect.
Cela garanti que Canaille a un comportement conforme pour la plupart des opérations OpenID Connect courantes.
Le processus de certification a révélé beaucoup d'erreurs d'interprétation, souvent mineures mais parfois importantes.
Nous avons corrigé la plupart des problèmes directement dans Authlib, la bibliothèque sous-jacente d'implémentation des normes.
Securité
Nous avons implémenté les recommandations restantes issues de l'audit de Radically Open Security.
La plupart étaient des recommandations mineures relevant des bonnes pratiques, mais il y avait tout de même une vulnérabilité à niveau de risque élevé.
Tout est corrigé désormais. Voici le rapport de sécurité.
Nous avons aussi documenté les recommandations de l'ANSSI concernant l'authentification et la gestion des mots de passe, que Canaille implémente.
La plupart des recommandations sont implémentées, il reste principalement à supporter WebAuthn.
Documentation
Nous travaillons continuellement sur la documentation, et visons de suivre les recommandations de Diátaxis.
Nous avons écrit des chapitres pour le premier lancement de Canaille et la configuration du premier client OpenID Connect.
Ces premières étapes nous indirectement fait travailler sur pydantic-settings-export, qui permet notamment aux utilisateurs d'exporter un fichier de configuration avec toutes les valeurs par défaut commentées et décrites, ce qui offre un bon point de départ pour commencer à adapter la configuration. Nous utilisons encore une implémentation personnalisée, le temps de faire remonter toutes les modifications dont nous avons besoin dans le projet original.
La suite
Canaille vise la simplicité et son périmètre fonctionnel est donc assez restreint.
Nous limitons donc le nombre de fonctionnalités que nous souhaitons implémenter, cepedant il en reste quelques unes :
Le support de WebAuthn comme facteur d'authentification.
Cela nous permettra d'implémenter les dernières recommandations de l'ANSSI qui manquent.
Le support d'une méthode de Captcha.
Il est à première vue étonnant d'inclure cette fonctionnalité à l'heure où la pertinence des Captchas s'amoindrit avec l'apparition des IAs.
Nous notons cependant que c'est une fonctionnalité essentielles pour certains utilisateurs, comme en témoigne le comparatif très poussé de solutions de SSO libres publié par la Contre-Voie l'année dernière.
L'implémentation d'un système de greffons personnalisés pour Canaille.
C'est à un horizon plus lointain, mais nous aimerions proposer une API pour que des développeurs puissent implémenter leur propre facteur d'authentification pour Canaille, ou bien leur propre connecteur de base de données.
À par ces fonctionnalités visibles, l'essentiel des évolutions à venir viendra sous le capot :
L'amélioration de la pile SCIM, notamment pour apporter le support des filtres SCIM.
L'amélioration de la pile OIDC pour apporter le support de nouvelles normes.
Notamment celles qui ont a trait à la déconnexion centralisée ou bien à la sécurité.
Our recent work on Canaille funded by NLNet Foundation brings us to release a beta version. Let's have a look on what changed.
Recent Work
Task Manager
We implemented a task manager that allows Canaille to perform long-running tasks asynchronously.
This is notably used to propagate SCIM requests or send emails.
The implementation uses dramatiq, and we published the dramatiq-eager-broker package which allows maintaining synchronous behavior in the test suite, and when the task manager is not configured.
OpenID Connect Certification
As we mentioned recently, Canaille obtained OpenID Connect Foundation certification last September.
This guarantees that Canaille behaves in compliance with most common OpenID Connect operations.
The certification process revealed many interpretation errors, often minor but sometimes significant.
We fixed most issues directly in Authlib, the underlying library implementing the standards.
Security
We implemented the remaining recommendations from the Radically Open Security audit.
Most were minor recommendations following best practices, but there was a high threat finding. Now everything is now in place. You can have a look at the report.
We also documented the ANSSI recommendations regarding authentication and password management, which Canaille implements.
Most recommendations are implemented, the main remaining task is to support WebAuthn.
Documentation
We continuously work on documentation, aiming to follow Diátaxis recommendations.
We wrote chapters for getting started with Canaille and configuring the first OpenID Connect client.
These initial steps indirectly led us to work on pydantic-settings-export, which notably allows users to export a configuration file with all default values commented and described, providing a good starting point to begin adapting the configuration. We're still using a custom implementation while we upstream all the changes we need to the original project.
What's Next
Canaille aims for simplicity and its functional scope is therefore quite limited.
We thus limit the number of features we want to implement, however a few remain:
WebAuthn support as an authentication factor.
This will allow us to implement the last missing ANSSI recommendations.
Captcha method support.
At first glance it's surprising to include this feature at a time when the relevance of Captchas is diminishing with the emergence of AIs.
However, we note that this is an essential feature for some users, as evidenced by the very thorough comparison of open source SSO solutions published by La Contre-Voie last year.
Implementation of a custom plugin system for Canaille.
This is on a more distant horizon, but we would like to offer an API so developers can implement their own authentication factor for Canaille, or their own database connector.
Besides these visible features, most upcoming developments will be under the hood:
Le protocole UVC (USB Video Class) définit la façon dont une caméra expose ses flux vidéo et ses contrôles à travers l’USB.
Il s’agit d’un protocole standardisé par l’USB-IF, utilisé par la quasi-totalité des webcams modernes : caméras internes de portables, modules USB, microscopes numériques, etc.
Sur Linux, c’est habituellement le module noyau uvcvideo qui gère ces périphériques et fournit une interface /dev/video* à travers V4L2.
Mais dans certains cas, on a besoin d’un accès plus bas-niveau, directement via libusb :
pour expérimenter des contrôles propriétaires, récupérer des images fixes (still image capture), inspecter les descripteurs, ou encore gérer des flux compressés que V4L2 ne supporte pas encore (H.265, VP8, AV1…).
Libusb-UVC vise à fournir une implémentation Python pure du protocole UVC :
indépendante du pilote noyau (uvcvideo peut rester chargé),
pilotable entièrement en espace utilisateur via libusb,
avec une API orientée objet et un outillage d’inspection complet.
Le but n’est pas de remplacer V4L2, mais de comprendre et explorer le protocole depuis l’espace utilisateur, pour le contrôle, le streaming et l’expérimentation.
Ce que fait la bibliothèque aujourd’hui
Streaming complet en userspace
Le module gère les flux YUYV et MJPEG en temps réel, avec reconstruction des trames, gestion de l’isochronisme et du changement d’alt-setting.
Les flux compressés (H.264, H.265, VPx, AV1…) sont également pris en charge en mode pass-through : la bibliothèque ne les décode pas, mais fournit les paquets bruts aux décodeurs en espace utilisateur (par exemple PyAV ou GStreamer).
Contrôles vidéo complets (VC)
Les unités standard (Input Terminal, Processing Unit) et les Extension Units propriétaires sont découvertes dynamiquement et peuvent être interrogées ou modifiées (GET_CUR, SET_CUR, etc.).
Un système de fichiers quirks JSON permet de documenter les GUIDs connus et de donner des noms explicites aux sélecteurs (par exemple les GUID Quanta ou Microsoft XU).
Gestion des images fixes (Still Image Capture)
Le protocole UVC 1.1 introduit la possibilité pour une caméra de capturer une image unique à la demande, avec éventuellement une résolution différente du flux vidéo.
Cette fonctionnalité a été implémentée : la bibliothèque sait envoyer la commande STILL_IMAGE_TRIGGER et récupérer la trame correspondante.
En pratique, aucune caméra testée jusqu’ici ne semble exposer de vrai mode still image, même si beaucoup déclarent les descripteurs correspondants.
Cela reste donc surtout une partie exploratoire du protocole, mais elle est fonctionnelle côté code.
Mode hybride avec le pilote du noyau
Si uvcvideo est chargé, la bibliothèque peut détacher uniquement l’interface de contrôle (VC) pour lire ou écrire les paramètres sans perturber les applications utilisant /dev/video*.
Le flux vidéo reste alors accessible via les outils classiques, ce qui permet un diagnostic fin sans avoir à décharger de module.
Inspection et génération de profils (quirks)
L’outil pyusb_uvc_info.py permet d’afficher toutes les interfaces, formats, résolutions et contrôles d’une caméra.
Il peut aussi générer un fichier JSON décrivant la structure de ses XU, utile pour la documentation ou le débogage.
Particularités et différences avec pyuvc
Contrairement à pyuvc (qui repose sur le pilote V4L2 et sur libjpeg-turbo pour le décodage MJPEG), Libusb-UVC ne s’appuie sur aucun pilote noyau.
Tout est géré via les transferts USB, en Python pur, ce qui permet de manipuler des flux que V4L2 ignore encore (par exemple des flux compressés modernes).
Pour le décodage, la bibliothèque peut déléguer à :
PyAV (binding FFmpeg) pour le décodage logiciel ou matériel,
GStreamer (via appsrc) pour des pipelines plus complexes,
tout en restant agnostique sur le backend.
Ce choix rend la bibliothèque beaucoup plus flexible que pyuvc, notamment pour des usages d’analyse ou de recherche.
Perspectives
Les prochaines étapes concernent :
la validation de nouveaux GUIDs d’Extension Units (Quanta, Realtek, Microsoft),
et la consolidation de la documentation technique (schémas des descripteurs, exemples de commandes GET_LEN et GET_INFO).
Avec Libusb-UVC, on a un outil libre et reproductible pour explorer le protocole UVC, comprendre les caméras, et permettre à d’autres de bâtir dessus.
Libusb-UVC offre un regard complet sur le protocole UVC depuis l’espace utilisateur.
C’est un outil utile pour les chercheurs, makers ou développeurs qui veulent comprendre comment une caméra dialogue réellement sur le bus USB —
et un bon point de départ pour aller au-delà de ce que propose V4L2.
Je suis en train de concevoir une application avec PySide 6, cette application génère un fichier pdf que je charge dans un QPdfDocument puis dans un QPdfView afin que l’utilisateur puisse le visualiser, je veux ensuite lui permettre de l’imprimer, mais je n’arrive pas à réaliser cette partie, c’est à dire celle de l’impression, j’ai essayé plusieurs solutions trouvées sur internet mais aucune ne marche, je suis juste arrivé à imprimer mais le fichier imprimé ne correspond pas à la taille ni la résolution voulue (A5). Je souhaiterais idéalement permettre une prévisualisation de la page à imprimer dans la boite de dialogue à imprimer.
je suis nouveau sur ce forum, et utilisateur occasionnel de python.
Je m’interroge sur la possibilité d’utiliser Python pour programmer du GRAFCET notamment sur des cartes type Raspberry PI.
En théorie, le GRAFCET n’est autre qu’un graphe assez proche des réseaux de Pétri et des machines à états finis et j’ai vu qu’il y avait des modules pythons.
Si quelqu’un a déjà fait l’expérience sur ce sujet, je l’en remercie.
Merci par avance pour vos aides!
Je m'explique, j'ai un serveur sous ubuntu. Il n'y a que un compte admin pour le moment.
J'ai fais appel à un stagiaire codeur pour créer et installer des codes python pour gérer Instagram notamment, installer des app sous ubuntu, modifier des fichiers comme Crontab,…
Comment faire pour avoir mes mots de passe de comptes privés tel que Instagram sans les dévoiler au codeur mais qu'il puisse faire fonctionner ces codes? Faàon fichier .env ou autre ? merci
