Benoît Sibaud a écrit 9300 commentaires

Si, l'adresse de courriel sera supprimée après un an si tu fermes ton compte ou si l'équipe fermes ton compte, et après 3 ans d'inactivité et 1 an sinon.

Le cas se présente de temps en temps, mais rarement : suivant les cas, une ancienne signature, le texte présent dans un contenu ou commentaire qui référence un lien vers un site perso ou un autre site, une ancienne version d'un contenu/commentaire dans un archiveur web, etc. On a déjà fait des réattributions.

La même question se pose potentiellement dans bien d'autres cas (tous aussi rares actuellement pour nous, mais pas inexistants) : comment convaincre/prouver que X est décédé et que son compte doit être fermé, que Y a changé de nom ou de sexe, que toto123@vieuxdomain.com de 1998 est bien la même personne que le toto123@vieuxdomain.com de 2023, etc. L'adresse de courriel n'est pas une solution miraculeuse non plus, mais ça reste bien pratique pour un « compte sur un simple site web ».

Boulette de ma part : c'est bien adresse IP de connexion courante et adresse IP de dernière connexion. Je corrige la dépêche ce sens. Merci.

Finalité : « avoir des données d’identification (…) pour gérer les litiges éventuels (par exemple, le manifestement illégal, le prétendument illégal) ou le cadre légal (par exemple, la modification des données de son propre compte, le droit d’auteur) ; » et « détecter des éventuels abus (comptes multiples, etc.). »

Les IP des logs web sont hors de la « base active », et ne sont pas forcément reliables à un compte (accès anonyme, IP commune à de multiples comptes, etc.). Les logs web sont conservés un an actuellement.

1. Non, ce n'est pas uniquement la dernière « connexion ». Ça peut être un ajout de commentaire, d'étiquette, de contenu, une édition des préférences du compte, etc. Une consultation ou modification du site faite avec le compte ?

2. Idéalement non, le monde du courriel est suffisamment détérioré pour que ça soit pénible d'envoyer des milliers de courriel sans être classé spammeur, en devant gérer les erreurs variées, etc. La première application va concerner des comptes particulièrement anciens (certains auront plus de 10 ans d'inactivité par exemple).

3. Oui c'est indiqué dans la dépêche d'ailleurs. « La principale différence concerne la conservation de l’adresse de courriel pour permettre une réouverture du compte et un envoi de nouveau mot de passe en cas de demande. »

C'est une suppression de la base active, ça laisserait la possibilité d'un archivage intermédiaire par exemple. Cf https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees
Ensuite ça reste un compromis / arbitrage entre la minimisation des données demandées par le RGPD et la durée du droit d'auteur en dizaines d'années ( et les coûts et la complexité pour une structure associative aussi). On parle d'une période intermédiaire de 1 an ou 3+1 ans, pendant laquelle la personne n'a pas réagi. Et au final, c'est à la personne qui a fermé son compte ou laissé son compte expiré de montrer qu'elle est bien cette personne… (de même que c'est à la personne qui a perdu son mot de passe et laissé une adresse de courriel invalide sur son compte de prouver qu'elle est bien cette personne). Cela ne compromet pas totalement mais clairement ça rendrait plus difficile.

La montée de questions écologiques peut jouer là-dessus : optimisation des chaînes CI/CD pour éviter de brûler une forêt à chaque commit, moins de ressources nécessaires à l'exécution (processeur, mémoire, batterie, disque, réseau, etc.). À condition que ça devienne un critère plus ou moins mesuré et pris en compte, évidemment.

Ouais y en a marre du porno dans les corbeilles a-t-il déclaré. Je vais aussi lancer un rm ******** pour supprimer les mots de passe qui traînent aurait-il ajouté. Avant de conclure oups, la boulette.

Corrigé, merci.

Et de 3

mamot.fr    4   0%
framapiaf.org   4   0%
piaille.fr  4   0% 

Et de deux:

framapiaf.org   4   0%
piaille.fr  4   0% 

Corrigé, merci.

Ce bug là est annoncé corrigé dans la version suivante 1.2.2 de yoga-image-optimizer. Cf https://github.com/flozz/yoga-image-optimizer/issues/41

mais elle a un autre souci chez moi…

$ yoga-image-optimizer images/sections/*.png 
Traceback (most recent call last):
  File "/home/oumph/.local/bin/yoga-image-optimizer", line 5, in <module>
    from yoga_image_optimizer.__main__ import main
  File "/home/oumph/.local/lib/python3.9/site-packages/yoga_image_optimizer/__main__.py", line 4, in <module>
    from .application import YogaImageOptimizerApplication
  File "/home/oumph/.local/lib/python3.9/site-packages/yoga_image_optimizer/application.py", line 20, in <module>
    from .image_store import ImageStore
  File "/home/oumph/.local/lib/python3.9/site-packages/yoga_image_optimizer/image_store.py", line 17, in <module>
    Pango.VERSION_MAJOR >= 1 and Pango.VERSION_MINOR >= 49
  File "/usr/lib/python3/dist-packages/gi/overrides/__init__.py", line 32, in __getattr__
    return getattr(self._introspection_module, name)
  File "/usr/lib/python3/dist-packages/gi/module.py", line 123, in __getattr__
    raise AttributeError("%r object has no attribute %r" % (
AttributeError: 'gi.repository.Pango' object has no attribute 'VERSION_MAJOR'

Je dirais que ma version est insuffisante (1.46 installée, pour une 1.49 nécessaire) :

ii  libpango-1.0-0:amd64       1.46.2-3     amd64        Layout and rendering of internationalized text

$ grep -n Pango  ~/.local/lib/python3.9/site-packages/yoga_image_optimizer/image_store.py
7:from gi.repository import Pango
17:    Pango.VERSION_MAJOR >= 1 and Pango.VERSION_MINOR >= 49

Une typo chttps:// au lieu de https://, corrigée, merci.

Temporairement, le remplacement des 75%% par small a fait l'affaire pour permettre l'optimisation des images.

$ grep -n small ~/.local/lib/python3.9/site-packages/yoga_image_optimizer/image_store.py
272:                        '<span font_size="small" font_weight="400">↓ %i×%i px</span>'
358:                    '%s\n<span font_size="small" font_weight="400">%s%s %%</span>'

cf https://github.com/linuxfrorg/linuxfr.org/commit/c1b56b0548b0475a98b6f6be4c93eb71c03ed57a

vu les évolutions des tailles, ça vaudrait le coup de passer une petite optimisation de taille des images. Mais pour le moment mon yoga-image-optimizer boude un peu donc ça va attendre…

(yoga-image-optimizer:17258): Gtk-WARNING **: 21:06:58.905: Failed to set text from markup due to error parsing markup: Value of 'size' attribute on <span> tag on line 2 could not be parsed; should be an integer no more than 2147483647, or a string such as 'small', not '75%'

On a largement dépassé les trois comptes mastodon renseignés, désormais.
Le maximum est de deux sur la même instance, actuellement.
Le suspense est à son comble.

• en tant que membre de l’équipe LinuxFr.org : le code en lui-même n’est pas versionné (autrement qu’être une succession de commits datés), ils sont annoncés dans les rétrospectives de la quinzaine mais sans effort particulier de vulgarisation, et parfois une dépêche vient décrire les nouveautés (il y en a une en rédaction par exemple).
• en tant que développeur, sur du code partagé mis à la disposition d’autres personnes (par exemple des rôles ansible communautaires) : quasi chaque commit donne lieu à une version, et donc je décris à chaque fois le changement (et l’étiquette x.y.z sur le commit permet aussi de savoir à quel point on a cassé la rétrocompatibilité). Mais je ne m’astreins pas à avoir en plus un fichier Changelog dans le dépôt.
• en tant que admin sys, avant de faire des mises à jour liées à du fonctionnel (ie. pas juste des mises à jour de sécurité, confiées aux équipes de la distribution par exemple), alors je parcours les notes de version notamment pour voir des ruptures de compatibilité éventuelles, ou des annonces de fonctions obsolètes ou en voie de l’être, ou des changements de configuration, ou même des nouvelles fonctionnalités qui pourraient m’intéresser. Souvent une lecture rapide en diagonale, parce que toute façon il est peu probable que je comprenne chaque ligne individuellement, sauf à connaître sur le bout des doigts le logiciel en question, et encore…
• en tant que simple utilisateur : ça dépend, je lis les notes de versions pour les montées de distribution Debian par exemple, j’essaie de lire les notes de versions de chaque application sur mobile (mais souvent c’est plus que sommaire « on a corrigé des trucs » et « on a amélioré les perfs ») mais c’est tellement fréquent…

En parlant de chiffres, peut-être un jour aura-t-on quelque chose dans la nouvelle partie « Domaine Mastodon » des « Statistiques sur les utilisatrices et utilisateurs », mais bon il faudrait plus de trois comptes Mastodon sur le même domaine… il faudrait plus de trois comptes Mastodon déjà… Suspense.

Tu parles des 3 qui ont déjà écrit une dépêche cette année ? Ça n'est pas vraiment lié à la modération, plus à leur activité globale sur le le site.

Parce que sinon il y a plus de 3 personnes qui ont voté sur les dépêches en modération, édité ces dépêches ou publié ces dépêches en janvier 2023 (bref qui ont été actives suivant ces statistiques imparfaites).

8e circo Français établis à l'étranger
https://webview.conseil-constitutionnel.fr/actualites/communique/decision-n-2022-5773-an-du-3-fevrier-2023-communique-de-presse
il a pu irrégulièrement être proposé aux électeurs de voter par internet à leur place en utilisant leurs identifiants et mots de passe.

La page « équipe » pourrait donc préciser que les administrateurs sont également modérateurs. Par exemple « L’actuelle équipe de modération est composée des administrateurs et de : […] ».

Oui.

sur LinuxFr le directeur de publication peut-il publier directement une dépêche (quand bien même ce serait exceptionnel) ?

Les admins du site ont une fonctionnalité 49.3 pour publier ou rejeter n'importe quelle dépêche en modération, sans avoir besoin des votes habituels. Et le directeur de publication est admin du site.

(Précisions sans grande importance dans le débat en cours)

À noter qu’il existe également une distinction entre l’association LinuxFr.org et l’équipe de modération sont deux choses différente.

L'association se nomme Linuxfr, et donne une entité légale au site, pour le compte bancaire et la responsabilité.

Ni le président, ni le vice président, ni le trésorier ne sont actuellement membres de l’équipe de modération il me semble, et je n’ai pas l’impression qu’un membre de l’actuelle équipe de modération soit membre de l’association (ou s’il y en a, ils sont minoritaires).

Les admins du site font partie de l'équipe de modération. Le président de l'association et le trésorier et divers autres membres de l'association en font partie. Ils sont probablement majoritaires d'ailleurs. Et un mini effet dans la modération via la règle cas limite Si trois personnes ou plus, comprenant au moins deux membres de l’association LinuxFr, se sont toutes exprimées pour la même décision, elle est considérée comme adoptée. (source https://linuxfr.org/regles_de_moderation_du_problematique
)

Par contre le directeur de publication est actuellement président de l’association, c’est peut-être une nécessité légale d’ailleurs.

Pas une nécessité légale (c'est le choix par défaut par contre). Il n'est pas obligatoire de faire reposer la responsabilité de l'association et celle des contenus du site sur la même personne.

Chronophage de répondre aux questions ? D'une part ça montre un intérêt, sur des tâches qui pourraient être faites dans l'indifférence complète, donc on ne va pas se plaindre d'avoir des questions :). C'est même plutôt bon pour la motivation je dirais. D'autre part ça aide à préparer la suite en réfléchissant au sujet et en mettant par écrit, pédagogiquement si possible. Plus d'autres aspects comme le fait de pouvoir partager avec d'autres personnes de l'équipe qui débuteraient ou connaîtraient moins le sujet, ou bien le fait que même tout seul je peux retrouver un vieux commentaire à moi et comprendre/redécouvrir ce que j'avais fait, quels étaient les chiffres de l'époque, etc.

10 ans c'est probablement trop long vu notre nécessité/besoin et ce que demande le RGPD. On n'a certes pas de données hypersensibles, mais pas grand chose ne justifie de les garder super longtemps non plus. Six ou sept ans serait un max a priori. Mais pour LinuxFr il faudrait plutôt choisir entre 1 an ou 3 ans ou 5 ans.

Mon idée serait de lancer une dépêche sous peu indiquant les changements envisagés, et de les appliquer à partir de la date anniversaire des 25 ans du site (fin juin donc), ce qui laisserait le temps aux gens qui le souhaitent de réagir, utiliser leur compte, fermer leur compte, etc.

C'est ce que je décris dans mon dernière paragraphe notamment. Actuellement, non, rien n'est fait automagiquement.