Stéphane Bortzmeyer a écrit 645 commentaires

On trouve de tout das tous les camps, c'est sûr. Mais bon, je ne vais pas parler à la place des femmes donc j'attends de voir (si elles souhaitent s'exprimer, ce qui n'est pas évident face à une discussion aussi lourdingue).

Je comprends ces arguments mais la question n'est pas tant de savoir si on préfère l'écriture inclusive ou pas (tout le monde ne sera pas d'accord et ça ne me dérange pas) mais de savoir si on accepte l'incroyable agressivité avec laquelle est accueilli tout article utilisant l'écriture inclusive (alors que les articles ne l'utilisant pas ne sont jamais dénoncés avec vigueur par les partisans de cette écriture).

C'est assez gonflé comme demande, alors que ce sont justement ceux qui réagissaient au titre de la dépêche qui se focalisaient sur la forme.

On pourrait penser que le linuxien moyen [pas d'écriture inclusive ici, pour une raison que vous allez comprendre] s'en fiche un peu (ce n'est pas vraiment une question informatique), et que de toute façon il n'écrit qu'en C, où le problème ne se pose pas. Mais, non, la question de l'écriture inclusive déchaine autant de réactions extrêmes ici que chez les vieux cons de l'Académie Française ou chez les lecteurs du Figaro, population pourtant a priori assez éloignée des manchotophiles libristes. (Il suffit de voir le nombre de votes négatifs, alors qu'il est plutôt rare d'en voir ici d'habitude.)

Donc, cool, les mecs [pas d'écriture inclusive ici, pour la même raison], personne n'en veut à votre virilité. Vous écrivez comme vous voulez et vous ne vous emballez pas comme ça parce que quelqu'un·e a fait autrement. Et arrêtez de réclamer qu'on écrive en « bon français ». Si les informaticiens se souciaient d'écrire en bon français, ça se saurait.

Concernant la fin de l'article (le déploiement des nouvelles versions de la norme), Daniel Stenberg a fait récemment un bon article expliquant pourquoi curl est toujours en C89.

« on se retrouve avec des choses qui ne fonctionnent pas de façon inattendue » C'est compliqué, le C :-)

Bon, je trolle, c'est un excellent article très détaillé, merci beaucoup.

Bon, mais la proposition d'API discutée ici est en lecture seule donc il n'y a pas du tout les mêmes problèmes de sécurité. Il s'agit de voir ses factures, pas de les régler.

En l'occurrence, ce n'est pas du tout une bonne idée (pour les raisons de vie privée déjà exposées) et il est tout à fait justifié de la critiquer.

Exiger une signature cryptographique est bien sûr raisonnable, afin d'éviter les faux mais soyons réalistes : imposer cela dans la norme tuerait complètement le projet. Déjà que les fournisseurs typiques auraient beaucoup de mal à déployer cette API, si en plus il fallait signer, on est parti pour des années de réunions, de délais, d'usines à gaz, etc.

Excellente idée globalement. Quelques remarques toutefois.

"endpoint /obapi/v1" C'est toujours une mauvaise idée d'avoir un préfixe de chemin en dur dans une norme. Le RFC 9205 explique pourquoi.

"errors attributes" Pourquoi ne pas s'appuyer sur le RFC 7807 plutôt que de re-développer une convention ?

La partie sur l'authentification me parait casse-gueule car elle réinvente un protocole de sécurité, ce qui est toujours dangereux. Je préférerai qu'on dise simplement qu'on mette la clé d'EPI dans l'en-tête. Et que l'obtention de la clé d'API dépend du fournisseur.

Mais ça n'a pas été retiré, c'est bien dans le chapo :-)

Zonemaster est en Perl (et activement développé).

L'argument des personnes disponibles me parait faible puisque Rust est une création de Mozilla. Ils n'utilisent donc pas leur propre langage ?

Pour des questions de sécurité, IMAP et SMTP ont été réécrits de C vers JavaScript.

Je croyais que c'était Rust qui était à la mode quand on voulait remplacer C pour des raisons de sécurité ?

Je suis déçu, personne n'a tapé sur Erlang/Elixir :-) La solution recommandée (mais pas la seule possible) dans ce monde est d'avoir une copie intégrale de toutes les dépendances (l'outil mix gère tout cela et peut télécharger depuis le dépôt de paquetages Hex, ou directement depuis un dépôt git). Ainsi, chaque programme est sûr d'avoir tout comme il veut (on peut spécifier la version désirée de plusieurs façons), une fermeture au sens mathématique du terme. Par contre, pas pratique du tout pour les petits scripts quick-and-dirty, ni quand il s'agit de patcher une faille de sécurité sur un module utilisé par plusieurs projets.

Plutôt que « data scientist » vs. les autres, je dirais que la tendance actuelle est de privilégier le développeur plutôt que l'utilisateur ou l'administrateur système (hashtag lutte des classes). Je ne crois pas qu'il soit possible d'avoir une solution qui plaise à tout le monde et je déplore que des gens défendent telle ou telle solution en prétendant qu'elle est « plus simple » ou « plus pratique », sans dire pour qui.

Téléchargement de la liste des serveurs DNS racines 

C'est inutile, Unbound (comme BIND et les autres) a tout ce qu'il faut (faites un strings sur /usr/bin/unbound si vous ne me croyez pas) et, de toute façon, utilise le "priming" (RFC 8109). Intervenir sur cette liste n'est utile que si on veut utiliser une racine alternative.

On peut utiliser ce script pour mettre à jours les serveurs DNS racines

Même remarque ici.

Cette absence d'agilité cryptographique est en effet une sérieuse erreur de conception de Wireguard (voir le RFC 7696 pour une explication). Un bon exemple est l'arrivée des algorithmes post-quantiques. Comment Wireguard va-t-il gérer cela ?

Il faut lire l'article avant : l'authentification a deux facteurs n'impose pas de passer par Google, elle se fait avec TOTP, une norme ouverte (RFC 6238) et pour laquelle il existe plein de mises en œuvre en logiciel libre.

Ah non, je ne crois pas que cette analyse soit correcte. La confidentialité persistante protège contre un vol de la clé privée, mais, si l'attaquant a enregistré toute la session, et s'il a un calculateur quantique, il peut s'attaquer à l'algorithme d'établissement des clés (par exemple ECDHE) et donc trouver les clés de session et tout déchiffrer.

La dépêche le dit mais le titre est trompeur : PyPi a 2FA depuis très longtemps. Il est déjà déployé, il s'agit juste de l'encourager.

--
Stéphane, développeur sur PyPi et ayant activé 2FA il y a des années :-)

L'authentification à facteurs multiples protège bien contre les tiers, et c'est donc une bonne idée que d'encourager son déploiement mais elle ne protège pas contre un développeur malveillant ou négligent (par exemple parce qu'il accepte des patches sans les lire). Donc, c'est bien, mais ce n'est pas suffisant.
Il n'y a pas de solution simple au problème des développeurs malveillants. Il n'est évidemment pas question d'auditer/certifier les développeurs de logiciels libres (qui aurait la légitimité de le faire, et selon quels critères ?)

Cela semble terriblement dangereux, des applications locales, vérifiées par personne, récupérées n'importe où, qui se lancent d'un clic et ont accès à toute la machine.

Pouquoi n'avoir pas cité CoAP / RFC 7252, qui est justement conçu pour cela ?

Ce code est aussi remarquablement écologique. Il serait difficile d'avoir une consommation énergétique plus faible.

BIMI est en effet loin d'être prêt. Contrairement à ce que prétend le marketing, ce n'est pas une technique d'authentification, et il n'a rien à voir avec la lutte contre le hameçonnage. C'est juste un moyen pour les grosses boites de s'imposer encore plus dans notre espace visuel en faisant afficher leur logo par notre logiciel. Comme si on ne voyait pas assez les marques.

Après une première tentative ratée de faire passer BIMI à l'IETF, une seconde tentative est en cours https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/