Stéphane Bortzmeyer a écrit 664 commentaires

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/

Ou bien le très connu forum gemini://station.martinrue.com/. Il est donc parfaitement possible d'écrire avec Gemini (même si le but n'est effectivement pas de faire 100 % de ce que fait le Web, c'est même tout le contraire).

Des logiciels libres de supervision, il en existe des millions, et tous peuvent tester IMAP et SMTP (par exemple pour ceux qui ont l'API Nagios, il y a les monitoring plugins https://www.monitoring-plugins.org/doc/man/check_smtp.html et https://www.monitoring-plugins.org/doc/man/check_imap.html).

Je pensais à tous les projets dont je m'occupais (persos ou pros) et qui avaient une base SQLite.

Dont plusieurs chez moi :-)

Dans la rubrique « Les nouveautés du Wiki », les liens ne marchent pas. Je clique sur le titre ou la date mais rien ne se passe. Testé uniquement avec Firefox sur Debian.

Du côté des normes techniques, on peut regarder le travail DTN à l'IETF (et le protocole Licklider). RFC 4838 https://www.bortzmeyer.org/4838.html et suivants.