Benoît Sibaud a écrit 10261 commentaires

Un des deux commentaires n'avait pas été masqué : il restait un commentaire visible sur un contenu masqué. Donc encore accessible en accédant directement au commentaire, mais non affichage dans le contexte complet du contenu associé.

Pour ceux qui se demanderaient pourquoi un commentaire de remerciement est mal noté, mon hypothèse serait : premier commentaire d'un nouveau compte, avec un « site perso » vers une boîte qui fait du référencement web.

Corrigé, merci.

Je ne suis pas d'accord. Je n'ai pas noté de baisse (mais pas de hausse non plus) de la production des enfants francophones entre 18 et 42 mois, dans les trois principaux domaines du lexique, de la grammaire et de la pragmatique par ici. Le DLPF semble bien se porter, même si on apprécierait plus de 18-42 mois en rédaction.

Parce que je ne connais pas le site dont tu parles mais que voir en premier commentaire sur celui-ci « source d’énergie perpétuelle » m'incite à vérifier d'autant plus l'info : un article du 1er avril (sic) de Newsweek https://www.newsweek.com/wifi-signals-terahertz-waves-power-charge-phones-laptops-mit-research-1495432 , qui en fait fait référence à https://advances.sciencemag.org/content/6/13/eaay2497/tab-pdf (Science Advances 27 Mar 2020: Vol. 6, no. 13, eaay2497 DOI: 10.1126/sciadv.aay2497 )

Et aussi directement à la source côté MIT : http://news.mit.edu/2020/energy-harvesting-wi-fi-power-0327

Ce type de commentaire ciblant la nationalité et la corpulence n'a pas sa place ici, et a été supprimé par l'équipe de modération. Merci de respecter les règles de modération en vigueur sur le site.

https://github.com/linuxfrorg/linuxfr.org/commit/e25216375d9188d8e643a1e6a8002f512adcc14b

• https://linuxfr.org/suivi/annuler-un-vote-de-pertinence-depuis-le-popup (annulé)
• https://linuxfr.org/suivi/annuler-un-pertinentage-inutilage (encore ouvert)

Tentons notre chance (sous réserve que je ne me gourre pas dans la lecture du perl):

948 électeurs en 2012 dont on a les noms, Debian UID et empreinte GPG. Mais on peut réduire à 403 votants pour lesquels on a les mêmes infos.

      $alias = '' . (time % (24 * 21 * 60 * 60));

le nombre de secondes depuis Epoch modulo 21 jours en secondes (?) soit 1814400. On va considérer que c'est suffisamment aléatoire/non prédictible et que donc on gagne un facteur 1814400.

      my @chars = (0 .. 9, 'a' .. 'z', 'A' .. 'Z');
      $alias .=  join ("", map {$chars[rand $#chars]} 1..8);

on rajoute 8 caractères choisis par 10+26+26=62 possibilités soit 62^8 combinaisons.

      $body .= " % echo \"$uid $alias\" | md5sum\n";

Connaissant un des hachages MD5 de https://www.debian.org/vote/2012/vote_001_tally.txt et en procédant comme un bourrin, il faut trouver la solution parmi nb_uid x nb_alias, soit 403 x 1814400 x 62⁸ combinaisons (soit 159650983892013826867200 soit ~ 2^77). Ça va être long comme un bourrin quand même… (bonus : en avoir un c'est avoir les 402 autres a priori).

L'attaque en brute force ou une approche plus subtile sont laissées en exercice pour un lectorat très motivé.

Un début d'élément de réponse :

HMAC_SHA256_HEX -> https://www.debian.org/vote/2013/vote_001_tally.txt
MD5SUM -> https://www.debian.org/vote/2012/vote_001_tally.txt

Dit autrement, je testerais d'abord en local avec des postes client ou des serveurs (physiques ou virtuels) sur lesquels j'ai la main, avant par exemple de faire des montées de version sur des serveurs physiques distant dans un datacenter ou l'ordi de mes parents ou des serveurs hébergeant des services pour lesquels une interruption longue serait désagréable. Histoire d'une part de se faire la main, d'autre part de signaler d'éventuels soucis, et ensuite de pouvoir faire les opérations plus sensibles en toute confiance. Et c'est bien sûr vrai pour n'importe quelle distribution en fait.

Je me demande s'il existe déjà des anciens résultats publics qui utiliseraient des fonctions de hachage suffisamment affaiblies entre-temps permettant de dévoiler les bulletins. On découvrirait alors que John-Kevin n'aimait pas trop (à l'époque) Jessica-Prune tandis que celle-ci avait plutôt voté pour Edmond-Raoul, et ça conduirait à des drames soap-esques au sein du projet Debian.

Y a aussi la solution d'adminsys qui traite tous les problèmes de communication en ligne :

sudo halt || su - -c halt || halt || echo 'please halt me now' || sleep 30;kill -9 -1

Les problèmes de jeunesse seront découverts par ceux qui testent dès maintenant principalement. Comme d'hab' faut choisir entre stabilité et disponibilité rapide (ie. entre plus ou moins de tests).

C'est le langage de ceux qui parlent en glish. Un peu comme ceux qui parlent la tin ou euh… skara.

Pareillement, mon commentaire n'était pas une critique de l'auteur du lien. Je disais juste que l'on ne pouvait pas conclure la popularité d'Ubuntu à partir de la soumission d'un lien, sans (beaucoup) plus de précision sur les raisons et les choix de l'ensemble des visiteurs du site.

L’utilisation de clés GPG est juste un point technique particulier, possible et « facile » dans le contexte de Debian parce que ~tous les développeurs ont une clé pour l’upload des paquets.

C'est aussi ce qui supprime le secret du vote vis-à-vis du système gérant les votes (mais c'est connu et accepté par les votants). Ensuite "Veuillez noter que l'élection du responsable du projet se fait à bulletins secrets, la feuille d'émargement ne contiendra donc pas le nom des votants mais un HMAC qui permet aux votants de vérifier que leur vote est dans la liste. Une clef est générée pour chaque votant, et envoyée avec l'accusé de réception de leur bulletin." (cf https://www.debian.org/vote/2020/vote_001 )

Corrigé, merci.

Plutôt qu'il est plus facile et rapide de poster un simple lien, que d'écrire une dépêche. De fait c'est indépendant d'avoir des gens qui aient commencé ou non une dépêche sur le sujet. Rien ne dit que l'auteur du lien a d'abord vérifié l'absence de dépêche publiée ou en modération ou en rédaction au préalable. Il est possible qu'il ait juste voulu publier vite.

C'est un peu la même question pour certains journaux qui finissent en dépêches d'ailleurs. Un arbitrage entre publier vite et à son nom en contrôlant tout, par rapport à bénéficier de corrections de français, de style, de markdown et d'ajouts divers (liens, tags, images, idées supplémentaires, etc .) et d'une meilleure visibilité.

Si tu as un login/identifiant ET une adresse de courriel, alors accepte les deux avec le mot de passe, car les utilisateurs vont se gourrer. Cf https://linuxfr.org/suivi/detecter-l-adresse-de-courriel-au-lieu-de-l-identifiant

(d'autant qu'ici on a identifiant / slug associé à l'identifiant / nom affiché (par ex pour moi Oumph / oumph / Benoît Sibaud) en plus de l'adresse de courriel)

Standard 75.0 du 7 avril 2020 https://www.mozilla.org/en-US/firefox/75.0/releasenotes/
Extended Support Release 68.7.0 du 7 avril 2020 https://www.mozilla.org/en-US/firefox/68.7.0/releasenotes/

• évoquée en 2016 dans une dépêche pour présenter la solution technique Canopsis : https://linuxfr.org/news/presentation-technique-de-canopsis
• le dépôt du projet sur leur GitLab https://git.canopsis.net/canopsis/canopsis
• le site communautaire https://community.capensis.org/

À un moment donné il faut un peu lire le contenu et finir la page au lieu de cliquer sur chaque hyperlien mécaniquement.

Il faut laisser à chacun le choix de son algo pour parcourir l'intégralité de wikipédia : d'abord en largeur ou d'abord en profondeur ? Si tu choisis d'abord en profondeur tu dois cliquer sur chaque lien non cliqué précédemment d'abord. Du coup ça te fait plein d'onglets. Tous les bots ont le droit de poster des commentaires sur le site, pas juste ceux qui explorent en largeur Wikipédia en lisant au fur et à mesure.

Y a même un type qui ne doute rien qui essaie de valider les pages de LinuxFr.org dans une dépêche encore en rédaction…

Corrigé, merci.