Mesdames et Messieurs,
Je voudrais vous inviter chaleureusement à Pycon Autriche 2025.
Malheureusement, mon français n’est pas assez bon pour le reste du message, je vais donc écrire en anglais:
Please share the following message among your members:
There will be a free international Python conference in Austria from 6th to 7th April 2025: https://at.pycon.org
(conference language will be English)
Entrance is for free but registration as a visitor, volunteer or speaker is necessary. Please register now because our places are limited.
It will be a conference about the Python programming language with free entrance for visitors, free community tables for python-related groups and open-source projects and paid tables for sponsors. Among talks and workshops, there will be recruiting sessions and talks / workshops dedicated to using Python in education.
Would you be interested to represent your group with a table (or a poster / booklets / advertising material) at the conference ?
It is the goal of the conference to make it easy for visitors to connect with active people from the python community in person. It is also a goal of the conference to present to conference visitors many parts of the complex Python ecosystem of libraries and open-source projects that are connected with the Python programming language.
Also, if possible, could you please spread the message about the conference and print out and publish this poster : https://drive.google.com/drive/folders/1peXO4pThfR289gb1hpT4Elq-hVodoMtT
Bonjour
Tout nouveau, dans le monde de python, j’essaye d’exécuter un script que j’ai trouvé sur ChatGPT pouvant permettre grâce à la caméra de faire bouger la souris. Voici le script.
import cv2
import pyautogui
# Chargement du classificateur de visage
face_cascade = cv2.CascadeClassifier(cv2.data.haarcascades + 'haarcascade_frontalface_default.xml')
# Initialisation de la capture vidéo
cap = cv2.VideoCapture(0)
# Boucle principale
while True:
# Capture d'une image
ret, frame = cap.read()
if not ret:
break
# Conversion en niveaux de gris
gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY)
# Détection des visages
faces = face_cascade.detectMultiScale(gray, scaleFactor=1.1, minNeighbors=5)
# Pour chaque visage détecté
for (x, y, w, h) in faces:
# Calcul de la position du centre du visage
center_x = x + w // 2
center_y = y + h // 2
# Déplacement de la souris
screen_width, screen_height = pyautogui.size()
pyautogui.moveTo(center_x * screen_width / frame.shape[1], center_y * screen_height / frame.shape[0])
# Dessiner un rectangle autour du visage (pour visualiser)
cv2.rectangle(frame, (x, y), (x + w, y + h), (255, 0, 0), 2)
L’ordinateur sur lequel j’essaye d’exécuter le script est un iMac tournant sur Catalina. Lorsque je glisse le script dans ma console, j’ai le message ci-dessous.
La version python installée sur l’ordinateur est la version 2.7.16
Bonjour,
sujet certainement trivial mais je ne comprends pas la différence entre:
lab1=Label(fen1, text = "label dans fen1", bg='bisque', font=("Verdana", 10))
lab1.place(x=xl, y=yl)
et lab1=Label(fen1, text = "label dans fen1", bg='bisque', font=("Verdana", 10)).place(x=xl, y=yl)
je n’ai pas trouvé d’explication mais c’est sûr il y a une différence de fonctionnement
Dans un lien récent sur LinuxFR, j'ai défendu la simplicité de mise en oeuvre de Python par rapport à C++…du moins au moins pour un POC, ou un petit script perso. Mais quand on développe un soft un peu plus complexe, eh bien j'avoue que pour ce qui est de tout le reste, autre que le pur développement, Python perd largement de son intérêt. Ou du moins, un bon langage compilé comme C++ , (je préfère, Rust) y gagne.
Un peu d'histoire
Si l'on a vanté la portabilité de C lors de sa sortie, ce n'est pas parce qu'un programme fonctionne tel quel sur n'importe quel OS/Architecture, mais parce qu'il compile a peu près sans changement, sur toute les architectures/OS. A l'époque, on programmait beaucoup en Assembleur ou alors chaque OS avait son propre langage. En C, on avait, et c'est toujours vrai, qu'a recompiler. Et même s'il peut toujours y avoir une dépendance a l'OS (Appels système) ou à l'Architecture (Big-Endian, Little-Endian), sur un OS/Architecture, on a qu'a vérifier les PATH et librairies… et si elles manque, c'est relativement simple à rajouter. On peut même compiler avec les librairies (empaqueter) (Sauf la libC).
Les langages interprétés
Depuis les premier OS, on a eu besoin de pouvoir lancer des programmes sans paser nécéssairement, par l'étape de compilation. Le premier langage interprété "en live" est le Shell (Bash, pour les Linuxien). L'énorme avantage, pour le développeur, c'est qu'il n'y a plus de risque de segfault (Il y a d'autres risque qui y sont du coup exacerbés, mais ce n'est pas le sujet). Cependant, il introduit un problème: c'est que le programme peut être parfaitement correct mais planter si l'interpréteur n'est pas à jour ou même parfois trop récent s'il n'y a pas de rétro-compatibilité. Et ça, c'est un véritable problème a plus d'un niveau pour le déploiement.
Si ce problème existe pour tout les langage interprété, paradoxalement, c'est quand la gestion des dépendance est trop simplifié et que le langage évolue trop qu'il est exacerbé.
Bash étant quasiment immuable (on peut parfois le déplorer), on a rarement des problèmes de ce type (Mais bien d'autres ;) ).
Pour Java, on galère, souvent avec les dépendances, mais somme toute le problème est assez limité. Comme c'est assez complexe d'ajouter des librairies, on en ajoute assez peu…
Pour Python, à contrario, c'est exacerbé. Comme on a des utilitaires comme PIP, on a trop souvent beaucoup de dépendances en cascades. Évidemment, les dépendances évitent de réinventer la roue. Cependant, pour chacune on a des contraintes sur leurs dépendances, voir sur la version du langage. On peut arriver au final a devoir gérer des dépendances complexes entre dépendances.
Les environnement virtuels, permettent simplement d'éviter les conflits avec les autres dépendances installées sur l'OS, mais on garde la même version du langage.
Un cas concret: le miens
Je développe OpenHEMS, un soft en Python, car c'est simple et que je m'appuie sur Home-Assistant et qu'au départ je voulais me contenter d'un script Home-Assistant. Ce soft intègre en dépendance le code-source (Car ce n'est plus complexe autrement) d'Emhass car ce soft intègre une gestion par IA éprouvé des panneaux solaires. Évidemment, j'ai envie de disposer de la dernière version d'Emhass (pour ne pas avoir les bugs, et les meilleurs fonctionnalités). Seulement, il utilise des fonctionnalités Python 3.10 (Je ne sais plus lesquels) et je souhaites le faire tourner sur une carte Open-Hardware (conformément à ma philosophie Open-Source) : Olinuximo. Seulement, OLinuXino ne propose que Debian 11 (C'est maintenu mais pas le dernier) et avec je n'ai que Python 3.9.
Au départ, j'ai pensé recompilé Python sur l'OS et l'embarqué. Cela me permet de gérer comme je veux mes dépendances. Oui mais voilà, ce n'est pas si simple, la compilation a fonctionné, mais je ne disposait pas de toutes les fonctionnalités. J'ai laissé tombé.
J'avais aussi voulu installé Emhass avec pip, mais le problème était plus grave encore, il m'installait une très ancienne version incompatible car elle avait été mal configuré. Et ce même avec Python3.12.
Ma solution : Docker
La manière la plus simple que j'ai trouvé (et sécurisé sans trop pénaliser les performances) c'est d'utiliser Docker. Mais du coup il faut se lancer dans une compilation docker (Avec Github).
Avec Docker OpenHEMS est beaucoup plus simple tester.
C'est aussi vrai que Docker sécurise OpenHEMS. Cela évite qu'une faille OpenHEMS permette de compromettre l'OS. De ce point de vue, c'est même plus sécurisé que de le faire tourner sous un user dédié. Mais cela coupe de tous les passe droits. Quand le logiciel tourne sous docker, il ne dispose pas de tous les accès à l'OS. Or OpenHEMS utilisait certains passe-droits:
1. Il tournait en root, ce qui me permettait de lancer le VPN pour un accès maintenance. Par sécurité (vie privé et autres), je ne veux pas laisser le VPN tourner en permanence. Je veux que l'utilisateur puisse autoriser manuellement la maintenance. J'ai donc utilisé un process root, un "pseudo-cron" qui se lance avec incron quand un fichier est modifié dans un répertoire spécifique.
2. Les logs étaient directement écris dans le /var/log/openhems, il faut un montage (Mais j'ai encore des problèmes là).
En fait, on peut lancer OpenHEMS sur Python 3.9 sans docker, mais on ne disposera pas de l'option Emhass ce qui est bloquant si l'on dispose de panneaux solaires…
PS : Peut-être n'ais-je pas fait les meilleurs choix. Je suis ouvert aux réflexions en commentaires.
En langage compilé
En langage compilé, (Rust j'aimerai), j'aurais certainement codé moins vite, mais j'aurais été plus rapide sur le déploiement. Concrètement, le problème de dépendance est géré à la compilation et on l'oublie trop souvent. Cette galère que j'ai bien connu en C/C++ évite bien des tracas après.
On ne peut pas dire qu'il n'y ait plus du tout de problème de dépendances. Tout le chalenge des distributions est de géré les conflits de version des librairies dynamiques. C'est tout de même minimisé.
En Python, c'est a un tel niveau que les distributions disposent toujours de Python2 en sus de Python3 (Alors que cela date) et que maintenant, on ne peut plus installer de dépendance avec pip (sur Debian du moins). On a accès qu'aux version disponibles et gérées par les mainteneurs de la distribution.
On se moque facilement des projets js qui vont et qui viennent mais python n’est pas en reste avec ses toolchains. Pour moi qui n’utilise pas beaucoup python, je dois perpétuellement me référer à la série d’articles pour vérifier quel outil est la “bonne” façon de faire (ou en tout cas pas trop désuète) et comment l’appeler (parce que python -m pip install requests ne me vient pas du premier coup).
Et l’autre jour on m’a dit qu’il y avait un outil qui a l’air super : uv. Encore un nouveau, super. Il lave plus blanc que blanc, il rend le poil brillant, il fait revenir l’être aimé,… ? Bien sûr et pour cocher toutes les cases il est écrit en rust.
Bon il s’avère que j’étais sur un petit outil en python donc essayons la doc d’installation :
curl -LsSf https://astral.sh/uv/install.sh | sh
(Quand je vais leur raconter ça sur linuxfr, faudra que ce soit un vendredi.)
Et l’usage ?
créer un projet ? uv init dossier
ajouter une dépendance ? uv add ma-super-bibliothèque
lancer mon projet ? uv run mon-script.py
Ok c’est rapide ça utilise un environnement virtuel, ça m’a créé quelques fichiers
pyproject.toml
uv.lock
.env/
.python-version
Ouai je vois bien à quoi sert chaque fichier.
Au final pour mon usage simple ça fait le job très bien. Je ne sais pas s’il peut servir à créer des wheel comme il faut etc, mais pour ce que je fais de python il a l’air simple et efficace. Il installe les dépendances plus vite que pip et les commandes sont simples à mémoriser.
Marco 'Lubber' Wienkoop pour son travail sur Fomantic-UI, un chouette framework CSS que nous utilisons dans canaille. Fomantic-UI est aussi utilisé par d'autres outils sur lesquels nous comptons, comme Forgejo.
Hsiaoming Yang pour son travail sur authlib, une bibliothèque python d'authentification que nous utilisons dans canaille.
Autrefois, il suffisait de demander un mot de passe pour vérifier l'identité d'une personne sur l'internet.
Cependant, il existe de multiples façons de deviner un mot de passe ou de le voler à quelqu'un, et les utilisateurs ont rapidement commencé à prendre des habitudes peu recommandables à leur égard, comme l'utilisation du même mot de passe sur tous les sites web.
Mais il n'y a pas que les mots de passe.
Les développeurs de logiciels se sont rendu compte que, surtout pour les applications sensibles, il n'est pas possible d'utiliser une seule méthode d'authentification : chacune d'entre elles présente des faiblesses et peut éventuellement être piratée.
La solution a consisté à demander aux utilisateurs de s'authentifier à l'aide d'au moins deux méthodes d'authentification, ou facteurs - d'où le nom d'authentification multifactorielle.
Pour un logiciel de gestion de l'identité comme Canaille, il s'agissait d'une fonctionnalité essentielle, et nous l'avons mise en œuvre pour quatre méthodes différentes :
Les méthodes HOTP/TOTP exigent que l'utilisateur télécharge et configure une application mobile ou un logiciel d'authentification (comme FreeOTP), qui produira à son tour des mots de passe à usage unique.
Ces mots de passe changent périodiquement (chaque fois que vous appuyez sur le bouton de votre authentificateur pour HOTP, ou après une période fixe pour TOTP), ce qui rend plus difficile pour les attaquants de mettre la main sur un mot de passe et de l'utiliser à temps.
Ce sont probablement les facteurs d'authentification les plus sûrs actuellement disponibles pour Canaille.
Les deux autres facteurs (codes par e-mail ou SMS) sont plus basiques mais offrent une meilleure sécurité lorsqu'ils sont combinés au mot de passe.
Ils pourraient être adaptés à des cas d'utilisation où la facilité d'utilisation semble plus importante que la sécurité.
La méthode du e-mail exige que les administrateurs de l'instance Canaille aient configuré un serveur SMTP.
De même, un serveur SMPP fonctionnel est nécessaire pour la méthode SMS.
Ces facteurs peuvent être cumulés, jusqu'à 3 facteurs différents (HOTP et TOTP, en utilisant la même application d'authentification, s'excluent mutuellement) en plus du mot de passe traditionnel.
L'utilisateur devra alors remplir tous les codes requis pour se connecter à son compte.
La fonction MFA peut également être complètement désactivée - dans ce cas, l'utilisateur n'aura besoin que de son mot de passe pour se connecter.
Verrouillage anti-intrusion
Pour empêcher les attaques par force brute sur les comptes Canaille, nous avons ajouté un délai entre chaque tentative de connexion échouée.
Ce délai est doublé chaque fois qu'un utilisateur saisit un mot de passe erroné.
Nous avons également envisagé de verrouiller les comptes après un certain nombre de tentatives infructueuses, mais cela aurait permis aux attaquants de verrouiller trop facilement tous les comptes d'utilisateurs.
Journalisation des événements de sécurité
Afin de faciliter la détection d'une attaque potentielle sur une instance de Canaille, nous avons ajouté la journalisation des événements sensibles.
Ces journaux sont marqués d'une étiquette spéciale "sécurité" pour faciliter leur récupération.
Les événements de sécurité enregistrés comprennent les tentatives d'authentification, les mises à jour de mot de passe ou d'e-mail, l'émission ou la révocation de jetons OAuth, etc.
Vérification de la compromission du mot de passe
Comme les utilisateurs ont tendance à réutiliser les mêmes mots de passe (avec quelques petites variations dans le meilleur des cas), il est désormais possible de vérifier si chaque nouveau mot de passe ne se trouve pas dans une base de données de mots de passe compromis, grâce à l'API de Have I Been Pwned.
HIBP offre un point de terminaison API gratuit qui peut être consulté pour les mots de passe compromis.
Politique d'expiration des mots de passe
Afin d'accroître la sécurité des comptes d'utilisateurs, il est désormais possible de déterminer une durée de vie pour les mots de passe.
Lorsqu'un mot de passe expire, les utilisateurs sont obligés de le mettre à jour lors de leur prochaine connexion, ou pendant leur session s'ils sont déjà connectés.
Approvisionnement avec SCIM
Canaille fournit une implémentation de serveur SCIM, qui peut être utilisée par les applications clientes pour gérer les utilisateurs et les groupes directement dans Canaille (avec les droits d'autorisation).
À l'avenir, nous aimerions créer une petite application de gestion d'abonnements à des services, et SCIM est un protocole bien adapté pour qu'une telle application puisse communiquer avec Canaille.
Grâce à nos récents travaux sur SCIM, nous avions presque tout prêt pour ajouter une implémentation côté serveur de SCIM.
C'était aussi un moyen de tester nos bibliothèques SCIM en situation réelle.
Au final, cette intégration nous a fait corriger beaucoup de choses aussi bien dans notre boîte à outils SCIM que dans Canaille.
Documentation
Internationalisation
Pour rendre Canaille plus accessible, nous avons passé du temps à rendre notre documentation traduisible.
L'interface de traduction est disponible sur Weblate.
Nous avons également traduit la documentation en français pour valider le mécanisme.
Ce fut également l’occasion pour nous de revoir toute la documentation existante et de corriger les erreurs de formulation et les fautes de frappe.
In the old days, asking for a password was considered sufficient to verify the identity of a person on the internet.
However, there are multiple ways to guess a password or steal it from someone, and users quickly began to form less than ideal habits around them - like using the same password on every websites.
But it's not just passwords.
Software developers came to the realization that, especially for sensitive applications, you can't get away with using a single authentication method: every one of them has its weaknesses, and can eventually be cracked.
The solution was found in asking users to authenticate themselves using two or more authentication methods, or factors - hence the name multi-factor authentication.
For an identity management software like Canaille, this was a key feature to have, and we implemented it for four different methods:
The HOTP/TOTP methods require the user to download and set up an authenticator mobile app or software (like FreeOTP), which will in turn produce one-time passwords.
These passwords change periodically (each time you press the button in your authenticator for HOTP, or after a fixed period for TOTP), which makes it harder for attackers to get their hands on a password and use it in time.
These are probably the most secure authentication factors available now for Canaille.
The remaining two factors (codes via email or SMS) are more basic but still offer a better security when combined with the password.
They might be adapted for use cases where ease of use appears more important than security.
The email method requires the administrators of the Canaille instance to have configured a SMTP server.
Likewise, a functioning SMPP server is needed for the SMS method.
These factors can be stacked, up to 3 different factors (HOTP and TOTP, using the same authenticator app, are mutually exclusive) in addition to the traditional password.
The user will then need to fill out all the required codes in order to log in to their account.
The MFA feature can also be deactivated completely - in that case the user will only need their password to login.
Intruder lockout
To prevent brute-force attacks on Canaille accounts, we added a delay between each failed login attempt.
The delay doubles each time someone enters a wrong password.
We also considered locking accounts after a given number of failed attempts, but this would have made it too easy for attackers to lock all user accounts.
Security events logging
In order to facilitate the detection of a potential attack on a Canaille instance, we added logging for sensitive events.
Those logs are marked with a special "security" tag for easy retrieval.
They can be configured to be written in a separate file than usual log entries.
Logged security events include authentication attempts, password or email updates, emission or revokation of OAuth tokens, and more.
Password compromise investigation
Since users tend to reuse the same passwords (with some small variations in the best case), it is now possible to check if each new password is not in a compromised passwords database, thanks to the Have I Been Pwned's API.
HIBP offers a free API endpoint that can be consulted for compromised passwords.
Password expiry policy
In order to increase the security of user accounts, it is now possible to determine a lifetime for passwords.
When a password expires, users are forced to update their password on their next login, or during their session if already logged in.
Provisioning with SCIM
Canaille provides a SCIM server implementation, that can be used by client applications to manage users and group directly in Canaille (given the rights permissions).
In the future we would love to build a small service subscription management application, and SCIM is a well suited protocol for such an application to communicate with Canaille.
Thanks to our recent work on SCIM we had almost everything ready to add a server-side implementation of SCIM.
It was also a way to test our SCIM libraries in a real-world situation.
In the end, this integration made us fix a lot of things both in our SCIM toolbox and in Canaille.
Documentation
Internationalization
To make Canaille more accessible, we spent some time to make our translation translatable.
The translation interface is available on Weblate.
We also translated the documentation in French to validate the mechanism.
This was also an opportunity for us to review all the existing documentation and fix wording errors and typos.
Theming
We also have worked on the theming documentation to help users customize how their Canaille instance looks.
We wanted to reference and document all our templates, to help designers modify them.
To achieve this we had to fork an old unmaintained library into a new library jinja-autodoc for automatic template documentation generation.
We cleaned it, made a few improvements, and pushed it under the sphinx-contrib organization.
