Voyons voir avec 2a01:cb19:XXXX:c001::2/64 (qui est dans le sous-réseau suivant) : paf, ça répond plus.
La livebox a un /56, mais ça ne de dit pas comment elle le route. Visiblement, :c001::/64 n'est pas un préfixe sur le lien Ethernet directement branché dessus. C'est classique, un seul préfixe — en l'occurrence :c000::/64 — est utilisé sur ce lien, et c'est suffisant. Comment crois-tu que sinon ta livebox saurait où aller chercher tous les périphériques dans ton /56 si elle devait au préalable interroger les machines branchées directement sur l'Ethernet ? (hint : il faut le temps du timeout NDP, qui n'est pas négligeable)
Alors je suis peut-être une quiche, j'ai raté un truc, je ne sais pas, mais la Livebox envoie des RA comme ça :
Non tu n'es pas une quiche, tu semble même plutôt bien informé. Regardons :
interface eth_livebox
{
[…]
AdvManagedFlag off;
Aïe ça commence mal, elle indique qu'il n'y a à priori pas de DHCPv6 sur ce réseau.
AdvOtherConfigFlag on;
Mais elle a un setup typique pour faire plaisir aux machines Windows qui n'impélementent(-aient ?) pas le RDNSS ; on sent les mecs qui veulent faire plaisir aux particularités pas très standards de MS.
Bon, du coup on sent que faire « standard » avec ce routeur va être peut-être un peu difficile.
Et j'ai essayé un client DHCPv6 : pas de réponse.
Aïe : tu as suivi la bonne piste, DHCPv6-PD étant la manière standard de déléguer un préfixe à un autre routeur, mais malheureusement les implémentations des FAI ne suivent pas.
Donc on en est là, toujours à faire du routage complexe pour rien, juste parce qu'il n'y a pas une case à cocher pour faire mieux qu'un simple /64 annoncé par la « box » elle-même, soit à peu près aussi utile que le NAT en IPv4. Oui c'est mieux, mais c'est tout aussi utile.
Effectivement. Et c'est exactement ce genre de problème qui fait partie des choses à changer pour rendre IPv6 praticable : changer la mentalité des opérateurs et leur faire comprendre qu'il faut suivre les standards. Ça n'est pas un problème technique, c'est quelque-chose de complètement politique, mais c'est indispensable pour qu'IPv6 marche bien.
Pour revenir sur l'intelligence dans le réseau je suis partagé. D'un côté, j'aime bien quand les routeurs n'en font pas trop, et de l'autre, beeeen, j'aimerais bien pouvoir choisir moi-même ce qui passe par où, sans avoir à le configurer sur toutes mes machines terminales. Du coup, en IPv4, vu qu'il y a un SNAT, c'est pas trop dur : certains paquets sont marqués par iptables, et les paquets marqués passent via la règle de SNAT différente.
Oui, l'opposition management centralisé vs. réparti aux extrémités est une question qui n'a pas de bonne réponse, et il existera toujours une tension entre les deux. Les organismes de standardisation tels que l'IETF sont remplis de gens qui ont des avis opposés là-dessus, et essayent de trouver un consensus. Néanmoins, les constatations empiriques font qu'en général, selon moi, il est plus pertinent de faire du décentralisé. Il est connu que les infrastructures réseau ont tendance à se scléroser, et que du coup toute configuration faite « au cœur » du réseau aura tendance à ne plus jamais bouger avec le temps. C'est d'après cette constatation qu'a été conçu IPv6 : il faut le protocole qui codifie le moins de choses possibles (on a dégagé la fragmentation des routeurs car ça fout la merde, encore énormément aujourd'hui en IPv4 avec la prolifération des tunnels de tunnels de tunnels et la frénésie du blackholing ICMP). Mais oui, centraliser la configuration est quelque-chose de désirable quand on administre beaucoup de machines : c'est alors qu'on invente des protocoles de configuration qui vont chercher la configuration (standardisée) de manière standard sur le réseau : c'est DHCPv6. Ainsi, tu propages ta configuration à tous les éléments de ton réseau depuis le cœur, mais sans dépendre d'un mécanisme qui va faire un truc intelligent au milieu. Pour moi, c'est le meilleur des deux mondes.
Sans parler après des problématique politiques de la volonté du réseau de contrôler ceux qui l'utilisent, quand ceux-ci sont issus d'autorités différentes : on tombe dans le débat sur la neutralité du Net. Je note en particulier que beaucoup d'admin réseau qui se bâtent pour la neutralité de leur FAI le sont beaucoup moins en ce qui concerne « leur » réseau à la maison, où leurs utilisateurs sont parfois sous la férule d'une non-neutralité imposée…
Le but, c'est bien d'éviter d'envoyer des paquets forgés via une machine potentiellement infectée.
Franchement, je suis sceptique sur l'utilité de se prémunir de ça : ton FAI filtrera de toutes façons, et si c'est comme tu dis du trafic illégitime, pas la peine d'essayer de le « traiter bien ».
Je ne pense pas qu'une telle règle filtre quoi que ce soit pour les paquets qui arrivent de l'extérieur.
On a dû mal se comprendre, je ne pense pas avoir dit ça.
La conclusion, c'est qu'il y a des centaines de personnes très qualifiées qui ont pondu un écosystème très perfectionné, et répondant parfaitement à quasiment tous les problèmes de IPv4, qui était quand même déjà bien conçu pour son époque.
C'est clair qu'IPv4 était déjà très bien foutu et est assez flexible pour s'adapter à un nombre de situations assez phénoménal. C'est le problème classique d'un protocole « assez bon » pour 80% des usages, qui fait qu'on a du mal à se motiver pour vouloir corriger les 20% restant (mais qui dans notre cas augmente de plus en plus).
Mais on se retrouve avec des tas de gens qui n'ont rien compris, ou ne veulent pas comprendre, et qui cassent tout ce beau travail.
Voilà, tu as bien compris le problème d'IPv6 : arriver à le faire comprendre. Malheureusement, avec la tendance actuelle à la pseudo-« sécurité » à tout prix, qui à tendance à favoriser le NAT pour de mauvaises raison, j'ai peur pour l'avenir d'IPv6. Mais oui, l'éducation reste la seule solution.
L’argument présenté du CDN et du CNAME est peut-être un des rares cas qui se tient vite-fait, mais à vrai dire le concept de CDN vient pallier l’absence de protocole adapté à ce besoin (par exemple des fonctionnalités de multicast, de P2P etc. changerait sérieusement la donne et serait beaucoup plus propre).
La bonne solution sans réinventer un protocole c'est de pousser à l'adoption des enregistrements SRV, qui peuvent servir aux usages pour lequel on fait habituellement du CDN tout comme d'autres choses (failover, serveur de backup, etc) : https://bugzilla.mozilla.org/show_bug.cgi?id=14328
Mais pour ça il va falloir se battre avec le code source de Firefox et la bureaucratie de Mozilla, appuyée par Google.
Et comme ça, on n'aura plus besoin de www tout en ayant bien mieux niveau fonctionnalités que ce palliatif.
Est-ce que la carte d'extension que tu présente ici est aussi ouverte que le CPU ? Ça n'a pas l'air d'être vraiment le cas : gros FPGA utilisable avec uniquement des outils proprios, IP fermées avec licences, etc. Je dis pas que c'est mal dans l'absolu, mais vu que le but du projet HiFive est de faire du matos libre, de ce que je comprends, ça fait un peu bizarre que tout ce qui permette d'en faire un desktop, qui est dans cette carte, soit fermé.
Merci d'avance pour les infos que tu pourras nous donner dessus.
Bien sûr je suis allé un peu vite, et ça n'est pas exactement cette option : celle-ci parle de la préférence d'une route qu'on annonce en particulier. La préférence du routeur en tant que routeur par défaut se fait avec :
AdvDefaultPreference low;
Bref, il y a encore quelques trucs auxquels faire attention en IPv6, mais ça avance !
Dans un monde « idéal », en IPv6, tu n'aurais pas forcément besoin de routeur intermédiaire, et tu aurais directement branché tes machinbox sur ton switch Ethernet, en précisant à ta box ADSL qu'elle est moins préférée (RFC 4191 https://tools.ietf.org/html/rfc4191), par exemple en syntaxe radvd.conf :
AdvRoutePreference low;
Et c'est tout.
Voilà, plutôt que de perdre du temps à continuer à bidouiller pour faire marcher IPv4, on pourrait se dire qu'il vaudrait mieux passer son temps à essayer de voir comment on pourrait faire mieux avec IPv6, et aider à corriger les problèmes de migration et les quelques défauts restants de ce « nouveau protocole », car oui IPv6 n'est pas parfait. À chaque fois que je dis ça on trouve mille excuses et on continue à « perdre » des millions d'heures d'ingénieur à essayer de trouver des rustines à IPv4, sans jamais s'arrêter, et sans jamais arriver à stopper l'érosion de ce protocole : on commence à ne vraiment plus avoir d'IP publique pour tout le monde, même sur les boxs, et bientôt le peer-to-peer sera tout simplement impossible. Plus personne ne pourra s'héberger, et la fiabilité du réseau sera exécrable, excepté pour ceux qui auront payé la bonne « qualité de service » (aussi bien pour les internautes que pour les fournisseurs de contenus ; notez la dichotomie, vous ne pourrez pas vous-même fournir de contenu) et seront capables de mettre les ressources serveurs adéquates en face pour mitiger le partage d'identifiant gigantesque qui arrivera, et de faire le tracking de connexion nécessaire. On arrivera bien sûr un jour à la limite du partage IP + port (ça n'ajoute que 16 bits en plus), et ça sera encore plus drôle à ce moment-là (j'imagine qu'on essayera de faire du multiplexage à l'intérieur de connexion TCP, voire UDP ; oups pardon https://en.wikipedia.org/wiki/Quic certains ont déjà prévu ce beau futur…).
Le multihoming — connecter son réseau à plusieurs fournisseurs d'accès — n'est pas un problème simple, et IPv6 n'a pas forcément de solution idéale à ce problème, mais le setup que je décrie respecte les principes de base de l'architecture d'Internet : l'intelligence n'est pas dans le réseau, et les décisions sur quelle liaison utiliser reviendraient aux machines utilisateur. Ça permet également de déporter la décision d'utiliser l'ADSL pour une raison particulière directement aux applications qui tournes sur les « extrémités » du réseau, sans avoir à toucher à un élément soit-disant intelligent au milieu (ton routeur). On ne fait également pas de routage source-specific (ton mangle + rule), qui est en général prompt aux erreurs de routage, cf. ton rp_filter qui est mignon, mais on voit bien que c'est chiant à gérer.
Note que si tu voulais un routeur intermédiaire — qui annoncerait deux préfixes issus de chacun des préfixe délégués plus larges alloués par chacun de tes opérateurs —, tu aurais toute de même à faire du routage source-specific avec un petit "ip rule" pour éviter le filtrage des opérateurs sur la source (BCP 38 https://tools.ietf.org/html/rfc2827 ; un peu comme ton rp_filter, en fait), mais ça se ferait sans marquage ni rien de compliqué, juste avec une sélection sur le préfixe utilisé en source qui détermine le next-hop adéquat :
ip -6 rule add from 2001:db8:1::/64 table isp1
ip -6 rule add from 2001:db8:2::/64 table isp2
ip -6 route add default table isp1 via fe80::XXX dev eth_livebox
ip -6 route add default table isp2 via fe80::XXX dev eth_adsl
Voilà. Pas d'état, pas de tracking, ça ne prend pas de mémoire, pas de resource, ça scale jusqu'à des Tbps, etc.
Bref, merci quand même pour ton journal, c'est marrant le « routage avancé » en IPv4, mais ça ne résoudra jamais le problème existentiel de l'Internet de l'ancien monde qui est en train de se dégrader : ça permettra juste à « ceux qui connaissent » de tenir encore un peu mieux que les autres, mais c'est tout. La seule solution universelle et durable s'appelle IPv6.
La critique du « besoin de défiscaliser » vient du fait que souvent, les personnes qui le font aiment bien critiquer en passant « l'État qui nous taxe tant », tout en grévant du budget de l'État la partie qui sera non-prélevée du fait du don. C'est en quelques sortes une manière d'orienter personnellement la politique d'investissement de l'État, tout en le critiquant, et tout ça au détriment de ce que l'État a désigné comme relevant du bien commun.
Donc non, ça n'est pas un fantasme, c'est une manière de promouvoir la liberté individuelle face au bien collectif, et de se faire mousser au passage avec de l'argent qui aurait sinon profité à tous.
Posté par benoar .
En réponse à la dépêche Firefox 61 & 62.
Évalué à 5.
Dernière modification le 21 septembre 2018 à 16:50.
Commentaire de Marco Bonardio, de Mozilla il semble, à propos du fait que la suppression de cette feature risque de faire perdre les descriptions précédemment stockées par ceux qui l'utilisaient :
I can't trust Mozilla with my data.)
FWIW, you can't trust anything regarding dataloss, that's why backup systems exist. Your hard drive could break tomorrow, or your OS may corrupt yesterday. You can't even trust your NAS unless it's enterprise grade (and still). I don't think this is a problem with Mozilla as it is not with any other company in the world.
Déjà depuis début 2016. Bon, je suppose que MS était en discussion depuis quelques temps avec GitHub avant de les acheter, donc ils auraient peut-être pu influencer les choix avant cette année, mais là ça commence à faire loin. Je ne sais pas trop quoi en penser.
Mais c'est sûr que maintenant, je pense que tu auras tout le mal du monde à essayer de faire accepter les od* en plus…
est-il préférable d'avoir tout le détail du code dans un arbre unique, avec tous les micro-commits, mais au moins on garde tout, pour toujours, et on peut tout retrouver
Tu peux faire un entre-deux, comme pour le noyau : le code intégré doit être formaté et séparé comme il faut, en commits ni trop gros ni étant des commit « de travail » (genre du « fix that », « update » ou « work in progress »). Les branches des devs sont retravaillées (rebasée) jusqu'à avoir une tête correcte pour pouvoir être mergée sans avoir les détails de comment le travail a été fait, mais plutôt le détail de la signification d'ensemble cohérents (genre on sépare le cœur d'une feature de son activation dans le reste du code). Toutes cette préparation est effectuée par échange de mails sur la LKML en ce qui concerne Linux.
Mais ça n'était pas satisfaisant pour moi, qui cherchait un découpage plus précis. Rechercher les patchs originaux de la branche de Linus n'est vraiment pas facile, mais ça serait en effet un travail intéressant, je pense.
Merci. Il y a également les deux derniers blame qui n'apparaissent pas pareil que les deux premiers. J'étais pressé et j'ai posté tel-quel.
Franchement j'ai horreur de markdown, j'ai toujours des incohérences incompréhensibles. Je fais toujours du ReST qui est beaucoup plus logique et vraiment puissant, tout en étant plus lisible. Pas étonnant que ça ait été le choix des devs noyau plutôt que du markdown…
Avoir une résolution DNS relative à un réseau et non globale a toujours été un problème car le DNS n'a pas été fait pour ça à la base. Toutes les solutions de DNS « privés » ou en split-view sont des gros hacks qui fonctionnent vaguement mais butent toujours à la conception même d'Internet : le DNS a une seule arborescence globale, et tout le monde devrait avoir un adressage global dans l'Internet pour ne pas avoir à faire des résolutions DNS relatives. Ce sont des fondements essentiels d'Internet qui sont cassés par le NAT et dont tout le monde espère trouver des workaround qui marchent toujours à moitié mal depuis 20 ans. Peut-être qu'un jour certaines personnes décideront de faire la bonne chose.
Si tu veux vraiment du DNS sur un réseau isolé, le mieux est mDNS comme cité plus haut. Ça marche à peu près partout (c'est standard https://tools.ietf.org/html/rfc6762 et implémenté de base dans pleins d'endroits) sauf sur les OS qui refusent le réseau décentralisé, et il se trouve que ce sont les majoritaires, Windows et Android. C'est malheureux mais je ne connais pas d'autre solution qui soit standard et pas trop crade.
Étrangement, il y a quelques jours j'ai vu un autre bug volontairement non-résolu dans Chromium, autre produit anti-décentralisation, qui casse volontairement les déploiements IPv6 isolés : https://bugs.chromium.org/p/chromium/issues/detail?id=530482
On comprend mieux cet état de fait quand on voit l'état d'esprit des devs Google : « can you explain more about why your configuration does not have a IPv6 global route? ». Ça fait peur de voir ce genre de commentaire par quelqu'un qui est censé implémenter et connaître IPv6 (il site plus haut les adresses site-locales, dépréciées depuis 15 ans…). Voir également le test de connectivité avec les adresses de Google hardcodées dans Chromium…
Bref, Google et consorts pèsent de tout leur poids politique pour casser les déploiements non-centralisés (ça me rappelle https://bugzilla.mozilla.org/show_bug.cgi?id=14328 où les devs qui déconseillent la résolution chez Mozilla viennent de… Google), et il est difficile de trouver des solutions dans ce cas-là.
attention, ce 2x le plafond c'est uniquement pour la convention Syntec. Pour les autres (métalurgie,…) ce n'est pas le cas.
Pour les autres, c'est au moins une fois le PMSS, effectivement. Soit 40 k€ brut par an, ce qui n'est souvent même pas ce que gagnent certains qui se disent au forfait.
Petit rappel à tous les ingés Syntec ou assimilé : vous n'êtes sûrement pas au forfait jour, comme j'entends beaucoup de salariés dire. C'est la substance du jugement condamnant Altran cité dans ce journal, qui indique que c'était pour « non-paiement d'heures supplémentaires », mais sans expliquer comment c'est arrivé (si je me souviens bien de l'histoire) : c'est parce-que les contrats soit-disant « au forfait » de beaucoup de salariés ont été requalifiés (après avoir été poursuivis en justice) en contrats classiques car ils ne satisfaisaient pas du tout les conditions nécessaires (grande autonomie, responsabilités) et les obligations (niveau salaire), et que donc toutes les heures effectuées en plus de la durée légale du travail (35h) sur les deux ou trois dernières années ont été comptées en tant qu'heure supplémentaires. Je suppose qu'Altran a également accepté de requalifier ces contrats car ils ne voulaient se plier aux obligations salariales requises pour un vrai forfait jour : un salaire d'au moins deux fois le PMSS (Plafond_de_la_Sécurité_sociale https://fr.wikipedia.org/wiki/Plafond_de_la_S%C3%A9curit%C3%A9_sociale 39 732 € en 2018), soit environ 80 k€ par an…
Je dirais dos d'âne ou ralentisseur, ce qui semble correspondre à la signification originale.
Non, c'est l'inverse, le but n'est pas de dire qu'un ralentisseur ralentit ton trafic, mais qu'un mécanisme « élève » (du verbe « to bump ») ton trafic réseau (le titre original est « A little bump in the wire that makes your Internet faster »). Ça a moyennement du sens ici pour la modification de scheduling, mais à l'origine c'était pour l'ajout d'un header IPsec (qui élève le contenu du paquet original).
Le terme « bump-in-the-wire » devrait plutôt être traduit, je pense, par « élévation sur la ligne », ou un truc du genre. Ça vient du monde IPsec, cf. https://en.wikipedia.org/wiki/Bump-in-the-wire qui référence la RFC 4301 https://tools.ietf.org/html/rfc4301 mais on peut remonter à la RFC 2767 https://tools.ietf.org/html/rfc2767 qui cite un papier de 1996 (sur une implémentation MS-DOS d'IPsec !!). On en parle par opposition au « bump-in-the-stack », ou « élévation dans la pile », dans lequelle c'est la pile logicielle qui est modifiée pour inclure l'amélioration ; de sécurité dans le cas d'IPsec, ici de réactivité, même si le « bump » est lié à l'ajout d'un header IPsec AH/ESP dans le premier cas et n'a pas ici vraiment de sens. On en parle également dans les différentes méthode de transition IPv4/IPv6.
Quant au bufferbloat, on pourrait éventuellement dire « ballonnements dû aux tampons » ; bon, je suis vraiment mauvais en francisation je crois.
Le pire est que l'industrie des télécoms toute entière refuse toujours obstinément de reconnaître ce problème, et le poids de l'existant est tellement énorme qu'il est en effet aujourd'hui impossible d'avoir une infrastructure DSL avec des tailles de buffer correctes, tellement c'est enraciné dans les équipements et les gens.
À chaque fois c'est le même débat qui tourne en boucle, sans jamais personne qui n'ait réellement eu entre les mains un tel système à gérer…
Avoir des bases de mot de passe chiffrées empêche toute authentification interactive « classique », qui permet de ne pas faire circuler le mot de passe sur le réseau, genre CHAP (rappelez-vous que Free à la base offrait des accès RTC où on s'authentifier avec du CHAP sur PPP…). Idem pour toute authentification interactive incluse dans EAP, pour reprendre un protocole un peu plus moderne. C'est également, je pense, une raison pour laquelle les gens semblent aimer le LDAP qui impose la méthode d'authentification avec une méthode de hashage fixée, et ne permet pas l'authentification interactive comme le permettrait RADIUS, qu'on mettrait normalement devant un LDAP.
Certes, aujourd'hui pour palier à la non-confidentialité des protocoles de vérification de mot de passe faisant passer le secret en clair comme PAP et pratiquement toutes les authentifications web « modernes », on ajoute du TLS en dessous et « tout va bien » ; c'est valable aussi bien pour le web que pour tout un paquet d'autres protocoles (comme EAP-TLS pour celui cité ci-dessus). Mais ces protocoles d'authentification sans gestion de la confidentialité étaient à l'origine pas très bien vus, et tous basés sur le principe de partage de secret identique, sans challenge.
Sans parler du fait qu'il existe des protocoles modernes (d'ou mon qualificatif de « classique » utilisé plus haut, par opposition) basés sur les mot de passe fait expressément pour ne pas avoir de base en clair, comme SCRAM https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism mais que tout le monde a l'air de s'en foutre.
Et bien sûr, tout cela en évitant l'éléphant dans la pièce : pourquoi a-t-on toujours autant d'histoires de mot de passes, avec une croissance et une complexité grandissante dans leur gestion, quand depuis des décennies on annonce l'avènement de l'authentification par cryptographie asymétrique ?!
Les deux images que j'ai postées se contentaient de montrer que Kate pouvait procéder à une part de cette abstraction mais de façon imparfaite : les longueurs des espaces insérés étaient certes dynamiques mais plusieurs espaces étaient quand même insérés.
Ce qui est exactement le fonctionnement d'une tab normale tel qu'implémenté dans tous les éditeurs depuis 30 ans. Ceci n'a rien à voir avec les tabulations élastiques, tu te méprends.
S'il fait référence aux logiciels de traitement de texte, évidemment que ceux-ci peuvent insérer des espaces de longueurs variables pour des besoins d'alignement. Seulement, aux dernières nouvelles, Kate ne fait pas de traitement de texte.
N'importe quel éditeur de texte qu'il soit « traitement de texte » ou pas a ce comportement que tu présente. Va vérifier. Encore une fois, rien à voir avec les tabulations élastiques, qui concernent le fait de faire de l'alignement de lignes adjacentes avec uniquement une seule tab (ce qui n'est pas le cas de ton exemple).
Note
Pour ce que ça vaut, mon opinion personnelle est que je préfère un jeton m’offrant une protection peut-être imparfaite mais dont je connais le code et les mécanismes, à une carte à puce m’offrant une protection certainement imparfaite également mais qui dépend d’informations que le constructeur de la puce refuse de dévoiler.
J'ai lu (il me semble) dans les publications de Gniibe qu'il préférait également l'utilisation d'un STM32 « standard » plutôt que d'un autre chip spécialement orienté crypto avec des fonctions « spécialisées » (et fermées), car il expliquait qu'on ne sait jamais ce que ça cache, et que ça finit toujours par être craqué un jour. Il est très orienté « liberté avant le reste », et comme tu le dis bien, la liberté et la documentation est préférable à tout autre argument de sécurité, même si le choix peut sembler moins sécurisé au début. Je partage cet avis aussi.
Et pour l'anecdote, j'ai connu GnuK à l'époque où pour le tester seul le kit Discovery STM8S était vraiment accessible niveau prix (et ça le reste encore : 7,55 € chez Farnell, mais la différence avec le F103 est négligeable aujourd'hui) : https://www.st.com/en/evaluation-tools/stm8s-discovery.html
Oui, le chip est un 8 bit, mais le chip qui fait l'interface UART-USB est un STM32F103, beaucoup plus puissant que la cible en question… Il contient moins de flash que le kit Nucleo, mais Gniibe a rajouté un hack car à priori, il aurait plus de flash que ce qu'indique la datasheet (perso, j'ai un patch pour désactiver des bouts afin que ça tienne dedans). Bon, ça reste un peu galère (en plus du port USB B assez gros), et je suis passé par un BusPirate pour le flash SWD, mais c'est drôle et pas cher.
En bossant sur les LNS de FDN, où arrivent toutes les connexions ADSL, je testais le fail-over de L2TPNS avec mes modifications pour annoncer les LNS en BGP aux routeurs upstream. Bien sûr, je teste depuis une ligne ADSL de chez FDN. Les deux serveurs sont up, les connexions sont réparties sur les deux, je coupe le premier : victoire, celles sur le premier basculent sur le second, ça fonctionne bien ! C'est vraiment époustouflant comme mécanisme, c'est quasi-instantané (quelque secondes) et toutes les lignes (environ 250 à l'époque, je crois) migrent sans problème. Confiant dans le système, je redémarre ce premier serveur, et « pour la forme » teste en coupant le second : allo ? Ya quelqu'un ? Ah, le fail-over n'a pas l'air d'avoir marché dans l'autre sens… Toutes les lignes sont tombées, y compris la mienne, et ça n'a pas l'air de redémarrer.
Bien sûr, on est dimanche soir minuit, et je n'ai donc plus d'accès au Net. Je ne suis pas à Paris ni Amiens, mais heureusement geb est dans le coin, lui pourra sûrement m'aider, je pars toquer à sa porte. En arrivant chez lui, il rigole bien, à priori la nouvelle s'est répandue assez vite sur IRC. C'est un autre Benjamin (bien nommé pour un dimanche) qui a vu la coupure et a redémarré les serveurs le temps que je fasse ma petite marche.
J'ai aussi appris plus tard par Domi que j'aurais pu me logger sur les serveur avec un realm et un login propre à notre fournisseur le collecte, vu l'architecture assez « open » du DSL en France.
[^] # Re: Comment on aurait fait en IPv6
Posté par benoar . En réponse au journal Routage avancé avec marquage de paquet et rp_filter. Évalué à 4.
La livebox a un /56, mais ça ne de dit pas comment elle le route. Visiblement, :c001::/64 n'est pas un préfixe sur le lien Ethernet directement branché dessus. C'est classique, un seul préfixe — en l'occurrence :c000::/64 — est utilisé sur ce lien, et c'est suffisant. Comment crois-tu que sinon ta livebox saurait où aller chercher tous les périphériques dans ton /56 si elle devait au préalable interroger les machines branchées directement sur l'Ethernet ? (hint : il faut le temps du timeout NDP, qui n'est pas négligeable)
Non tu n'es pas une quiche, tu semble même plutôt bien informé. Regardons :
Aïe ça commence mal, elle indique qu'il n'y a à priori pas de DHCPv6 sur ce réseau.
Mais elle a un setup typique pour faire plaisir aux machines Windows qui n'impélementent(-aient ?) pas le RDNSS ; on sent les mecs qui veulent faire plaisir aux particularités pas très standards de MS.
Et qui est du genre neuneu-proof.
Donc, le préfixe que tu utilises normalement.
Une jolie configuration DNS par IPv6, bien.
Ils n'ont pas l'air d'aimer suivre les standard http://www.bortzmeyer.org/7788.html même si la pratique « de fait » de ce genre de réservation sauvage à conduit à laisser faire ce genre de truc http://www.bortzmeyer.org/8244.html.
Bon, du coup on sent que faire « standard » avec ce routeur va être peut-être un peu difficile.
Aïe : tu as suivi la bonne piste, DHCPv6-PD étant la manière standard de déléguer un préfixe à un autre routeur, mais malheureusement les implémentations des FAI ne suivent pas.
Effectivement. Et c'est exactement ce genre de problème qui fait partie des choses à changer pour rendre IPv6 praticable : changer la mentalité des opérateurs et leur faire comprendre qu'il faut suivre les standards. Ça n'est pas un problème technique, c'est quelque-chose de complètement politique, mais c'est indispensable pour qu'IPv6 marche bien.
Oui, l'opposition management centralisé vs. réparti aux extrémités est une question qui n'a pas de bonne réponse, et il existera toujours une tension entre les deux. Les organismes de standardisation tels que l'IETF sont remplis de gens qui ont des avis opposés là-dessus, et essayent de trouver un consensus. Néanmoins, les constatations empiriques font qu'en général, selon moi, il est plus pertinent de faire du décentralisé. Il est connu que les infrastructures réseau ont tendance à se scléroser, et que du coup toute configuration faite « au cœur » du réseau aura tendance à ne plus jamais bouger avec le temps. C'est d'après cette constatation qu'a été conçu IPv6 : il faut le protocole qui codifie le moins de choses possibles (on a dégagé la fragmentation des routeurs car ça fout la merde, encore énormément aujourd'hui en IPv4 avec la prolifération des tunnels de tunnels de tunnels et la frénésie du blackholing ICMP). Mais oui, centraliser la configuration est quelque-chose de désirable quand on administre beaucoup de machines : c'est alors qu'on invente des protocoles de configuration qui vont chercher la configuration (standardisée) de manière standard sur le réseau : c'est DHCPv6. Ainsi, tu propages ta configuration à tous les éléments de ton réseau depuis le cœur, mais sans dépendre d'un mécanisme qui va faire un truc intelligent au milieu. Pour moi, c'est le meilleur des deux mondes.
Sans parler après des problématique politiques de la volonté du réseau de contrôler ceux qui l'utilisent, quand ceux-ci sont issus d'autorités différentes : on tombe dans le débat sur la neutralité du Net. Je note en particulier que beaucoup d'admin réseau qui se bâtent pour la neutralité de leur FAI le sont beaucoup moins en ce qui concerne « leur » réseau à la maison, où leurs utilisateurs sont parfois sous la férule d'une non-neutralité imposée…
Franchement, je suis sceptique sur l'utilité de se prémunir de ça : ton FAI filtrera de toutes façons, et si c'est comme tu dis du trafic illégitime, pas la peine d'essayer de le « traiter bien ».
On a dû mal se comprendre, je ne pense pas avoir dit ça.
C'est clair qu'IPv4 était déjà très bien foutu et est assez flexible pour s'adapter à un nombre de situations assez phénoménal. C'est le problème classique d'un protocole « assez bon » pour 80% des usages, qui fait qu'on a du mal à se motiver pour vouloir corriger les 20% restant (mais qui dans notre cas augmente de plus en plus).
Voilà, tu as bien compris le problème d'IPv6 : arriver à le faire comprendre. Malheureusement, avec la tendance actuelle à la pseudo-« sécurité » à tout prix, qui à tendance à favoriser le NAT pour de mauvaises raison, j'ai peur pour l'avenir d'IPv6. Mais oui, l'éducation reste la seule solution.
[^] # Re: www ou non
Posté par benoar . En réponse à la dépêche Évolution des hyperliens sur LinuxFr.org. Évalué à 4.
La bonne solution sans réinventer un protocole c'est de pousser à l'adoption des enregistrements SRV, qui peuvent servir aux usages pour lequel on fait habituellement du CDN tout comme d'autres choses (failover, serveur de backup, etc) : https://bugzilla.mozilla.org/show_bug.cgi?id=14328
Mais pour ça il va falloir se battre avec le code source de Firefox et la bureaucratie de Mozilla, appuyée par Google.
Et comme ça, on n'aura plus besoin de www tout en ayant bien mieux niveau fonctionnalités que ce palliatif.
# Ouverture de la carte d'extension ?
Posté par benoar . En réponse au journal Risc-V est prêt pour le desktop™ !. Évalué à 2.
Est-ce que la carte d'extension que tu présente ici est aussi ouverte que le CPU ? Ça n'a pas l'air d'être vraiment le cas : gros FPGA utilisable avec uniquement des outils proprios, IP fermées avec licences, etc. Je dis pas que c'est mal dans l'absolu, mais vu que le but du projet HiFive est de faire du matos libre, de ce que je comprends, ça fait un peu bizarre que tout ce qui permette d'en faire un desktop, qui est dans cette carte, soit fermé.
Merci d'avance pour les infos que tu pourras nous donner dessus.
[^] # Re: Comment on aurait fait en IPv6
Posté par benoar . En réponse au journal Routage avancé avec marquage de paquet et rp_filter. Évalué à 4.
Bien sûr je suis allé un peu vite, et ça n'est pas exactement cette option : celle-ci parle de la préférence d'une route qu'on annonce en particulier. La préférence du routeur en tant que routeur par défaut se fait avec :
Bref, il y a encore quelques trucs auxquels faire attention en IPv6, mais ça avance !
# Comment on aurait fait en IPv6
Posté par benoar . En réponse au journal Routage avancé avec marquage de paquet et rp_filter. Évalué à 10.
Dans un monde « idéal », en IPv6, tu n'aurais pas forcément besoin de routeur intermédiaire, et tu aurais directement branché tes machinbox sur ton switch Ethernet, en précisant à ta box ADSL qu'elle est moins préférée (RFC 4191 https://tools.ietf.org/html/rfc4191), par exemple en syntaxe radvd.conf :
Et c'est tout.
Voilà, plutôt que de perdre du temps à continuer à bidouiller pour faire marcher IPv4, on pourrait se dire qu'il vaudrait mieux passer son temps à essayer de voir comment on pourrait faire mieux avec IPv6, et aider à corriger les problèmes de migration et les quelques défauts restants de ce « nouveau protocole », car oui IPv6 n'est pas parfait. À chaque fois que je dis ça on trouve mille excuses et on continue à « perdre » des millions d'heures d'ingénieur à essayer de trouver des rustines à IPv4, sans jamais s'arrêter, et sans jamais arriver à stopper l'érosion de ce protocole : on commence à ne vraiment plus avoir d'IP publique pour tout le monde, même sur les boxs, et bientôt le peer-to-peer sera tout simplement impossible. Plus personne ne pourra s'héberger, et la fiabilité du réseau sera exécrable, excepté pour ceux qui auront payé la bonne « qualité de service » (aussi bien pour les internautes que pour les fournisseurs de contenus ; notez la dichotomie, vous ne pourrez pas vous-même fournir de contenu) et seront capables de mettre les ressources serveurs adéquates en face pour mitiger le partage d'identifiant gigantesque qui arrivera, et de faire le tracking de connexion nécessaire. On arrivera bien sûr un jour à la limite du partage IP + port (ça n'ajoute que 16 bits en plus), et ça sera encore plus drôle à ce moment-là (j'imagine qu'on essayera de faire du multiplexage à l'intérieur de connexion TCP, voire UDP ; oups pardon https://en.wikipedia.org/wiki/Quic certains ont déjà prévu ce beau futur…).
Le multihoming — connecter son réseau à plusieurs fournisseurs d'accès — n'est pas un problème simple, et IPv6 n'a pas forcément de solution idéale à ce problème, mais le setup que je décrie respecte les principes de base de l'architecture d'Internet : l'intelligence n'est pas dans le réseau, et les décisions sur quelle liaison utiliser reviendraient aux machines utilisateur. Ça permet également de déporter la décision d'utiliser l'ADSL pour une raison particulière directement aux applications qui tournes sur les « extrémités » du réseau, sans avoir à toucher à un élément soit-disant intelligent au milieu (ton routeur). On ne fait également pas de routage source-specific (ton mangle + rule), qui est en général prompt aux erreurs de routage, cf. ton rp_filter qui est mignon, mais on voit bien que c'est chiant à gérer.
Note que si tu voulais un routeur intermédiaire — qui annoncerait deux préfixes issus de chacun des préfixe délégués plus larges alloués par chacun de tes opérateurs —, tu aurais toute de même à faire du routage source-specific avec un petit "ip rule" pour éviter le filtrage des opérateurs sur la source (BCP 38 https://tools.ietf.org/html/rfc2827 ; un peu comme ton rp_filter, en fait), mais ça se ferait sans marquage ni rien de compliqué, juste avec une sélection sur le préfixe utilisé en source qui détermine le next-hop adéquat :
Voilà. Pas d'état, pas de tracking, ça ne prend pas de mémoire, pas de resource, ça scale jusqu'à des Tbps, etc.
Bref, merci quand même pour ton journal, c'est marrant le « routage avancé » en IPv4, mais ça ne résoudra jamais le problème existentiel de l'Internet de l'ancien monde qui est en train de se dégrader : ça permettra juste à « ceux qui connaissent » de tenir encore un peu mieux que les autres, mais c'est tout. La seule solution universelle et durable s'appelle IPv6.
[^] # Re: [HS] "besoin de défiscaliser "
Posté par benoar . En réponse à la dépêche Parution de GNOME 3.30. Évalué à 7.
La critique du « besoin de défiscaliser » vient du fait que souvent, les personnes qui le font aiment bien critiquer en passant « l'État qui nous taxe tant », tout en grévant du budget de l'État la partie qui sera non-prélevée du fait du don. C'est en quelques sortes une manière d'orienter personnellement la politique d'investissement de l'État, tout en le critiquant, et tout ça au détriment de ce que l'État a désigné comme relevant du bien commun.
Donc non, ça n'est pas un fantasme, c'est une manière de promouvoir la liberté individuelle face au bien collectif, et de se faire mousser au passage avec de l'argent qui aurait sinon profité à tous.
[^] # Re: Mes descriptions...
Posté par benoar . En réponse à la dépêche Firefox 61 & 62. Évalué à 5. Dernière modification le 21 septembre 2018 à 16:50.
Commentaire de Marco Bonardio, de Mozilla il semble, à propos du fait que la suppression de cette feature risque de faire perdre les descriptions précédemment stockées par ceux qui l'utilisaient :
Avec cette mentalité, forcément…
[^] # Re: C'est vieux apparemment
Posté par benoar . En réponse au message Github ne supporte pas (les fichiers) libreoffice (en pièces jointes des tickets) ?. Évalué à 3.
Et je pourrais dire « LOL », dans une annonce vaguement liée à ce sujet, Google vient d'investir 100 M$ dans GitLab : https://www.latribune.fr/technos-medias/internet/logiciel-libre-gitlab-leve-100-millions-de-dollars-et-devient-une-licorne-791109.html
Bref, si vous voulez un peu plus de contrôle sur votre hébergement de projet, hébergez-le vous-même.
# C'est vieux apparemment
Posté par benoar . En réponse au message Github ne supporte pas (les fichiers) libreoffice (en pièces jointes des tickets) ?. Évalué à 3.
Je me demandais si c'était arrivé après le rachat par MS. Ça ne semble pas le cas :
http://web.archive.org/web/20160316000110/https://help.github.com/articles/file-attachments-on-issues-and-pull-requests/
Déjà depuis début 2016. Bon, je suppose que MS était en discussion depuis quelques temps avec GitHub avant de les acheter, donc ils auraient peut-être pu influencer les choix avant cette année, mais là ça commence à faire loin. Je ne sais pas trop quoi en penser.
Mais c'est sûr que maintenant, je pense que tu auras tout le mal du monde à essayer de faire accepter les od* en plus…
[^] # Re: Chez la concurrence
Posté par benoar . En réponse au journal Btrfs restore à la rescousse. Évalué à 2.
man qemu-system :
Mais tu ne vas pas aller très loin avec ton système qui ne pourra rien écrire sur le disque.
[^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?
Posté par benoar . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 7. Dernière modification le 19 septembre 2018 à 10:25.
Tu peux faire un entre-deux, comme pour le noyau : le code intégré doit être formaté et séparé comme il faut, en commits ni trop gros ni étant des commit « de travail » (genre du « fix that », « update » ou « work in progress »). Les branches des devs sont retravaillées (rebasée) jusqu'à avoir une tête correcte pour pouvoir être mergée sans avoir les détails de comment le travail a été fait, mais plutôt le détail de la signification d'ensemble cohérents (genre on sépare le cœur d'une feature de son activation dans le reste du code). Toutes cette préparation est effectuée par échange de mails sur la LKML en ce qui concerne Linux.
[^] # Re: Correction
Posté par benoar . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 3. Dernière modification le 19 septembre 2018 à 10:18.
Merci pour les corrections, c'est beaucoup plus lisible.
J'avais oublié les ```, en effet, ça semble plus simple.
[^] # Re: En fabriquer un dépôt git pour l'historique?
Posté par benoar . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 7. Dernière modification le 19 septembre 2018 à 08:23.
C'est un projet qui a été mené par Dave Jones, comme cité dans la page SO. Il a un dépôt du code utilisé :
https://github.com/kernelslacker/linux-historic-scripts
Et la page qui héberge le résultat :
https://archive.org/details/git-history-of-linux
Mais ça n'était pas satisfaisant pour moi, qui cherchait un découpage plus précis. Rechercher les patchs originaux de la branche de Linus n'est vraiment pas facile, mais ça serait en effet un travail intéressant, je pense.
[^] # Re: Correction
Posté par benoar . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 4.
Merci. Il y a également les deux derniers blame qui n'apparaissent pas pareil que les deux premiers. J'étais pressé et j'ai posté tel-quel.
Franchement j'ai horreur de markdown, j'ai toujours des incohérences incompréhensibles. Je fais toujours du ReST qui est beaucoup plus logique et vraiment puissant, tout en étant plus lisible. Pas étonnant que ça ait été le choix des devs noyau plutôt que du markdown…
[^] # Re: Chez la concurrence
Posté par benoar . En réponse au journal Btrfs restore à la rescousse. Évalué à 3.
Oui mais monter le volume en read-only, c'est pas drôle. Je pense que raphj parlait de monter en R/W…
# Pas facile
Posté par benoar . En réponse au message Configuration DNS et domaine. Évalué à 2.
Avoir une résolution DNS relative à un réseau et non globale a toujours été un problème car le DNS n'a pas été fait pour ça à la base. Toutes les solutions de DNS « privés » ou en split-view sont des gros hacks qui fonctionnent vaguement mais butent toujours à la conception même d'Internet : le DNS a une seule arborescence globale, et tout le monde devrait avoir un adressage global dans l'Internet pour ne pas avoir à faire des résolutions DNS relatives. Ce sont des fondements essentiels d'Internet qui sont cassés par le NAT et dont tout le monde espère trouver des workaround qui marchent toujours à moitié mal depuis 20 ans. Peut-être qu'un jour certaines personnes décideront de faire la bonne chose.
Une description un peu plus formelle du genre de problème auquel tu fais face : https://tools.ietf.org/html/rfc6418
Si tu veux vraiment du DNS sur un réseau isolé, le mieux est mDNS comme cité plus haut. Ça marche à peu près partout (c'est standard https://tools.ietf.org/html/rfc6762 et implémenté de base dans pleins d'endroits) sauf sur les OS qui refusent le réseau décentralisé, et il se trouve que ce sont les majoritaires, Windows et Android. C'est malheureux mais je ne connais pas d'autre solution qui soit standard et pas trop crade.
Étrangement, il y a quelques jours j'ai vu un autre bug volontairement non-résolu dans Chromium, autre produit anti-décentralisation, qui casse volontairement les déploiements IPv6 isolés : https://bugs.chromium.org/p/chromium/issues/detail?id=530482
On comprend mieux cet état de fait quand on voit l'état d'esprit des devs Google : « can you explain more about why your configuration does not have a IPv6 global route? ». Ça fait peur de voir ce genre de commentaire par quelqu'un qui est censé implémenter et connaître IPv6 (il site plus haut les adresses site-locales, dépréciées depuis 15 ans…). Voir également le test de connectivité avec les adresses de Google hardcodées dans Chromium…
Bref, Google et consorts pèsent de tout leur poids politique pour casser les déploiements non-centralisés (ça me rappelle https://bugzilla.mozilla.org/show_bug.cgi?id=14328 où les devs qui déconseillent la résolution chez Mozilla viennent de… Google), et il est difficile de trouver des solutions dans ce cas-là.
[^] # Re: Rappel sur la réalité du soit-disant « forfait jour »
Posté par benoar . En réponse au journal Chaque été depuis 9 ans, Altran enclenche une procédure de licenciement contre un délégué syndical. Évalué à 5. Dernière modification le 03 septembre 2018 à 11:13.
Pour les autres, c'est au moins une fois le PMSS, effectivement. Soit 40 k€ brut par an, ce qui n'est souvent même pas ce que gagnent certains qui se disent au forfait.
# Rappel sur la réalité du soit-disant « forfait jour »
Posté par benoar . En réponse au journal Chaque été depuis 9 ans, Altran enclenche une procédure de licenciement contre un délégué syndical. Évalué à 10.
Petit rappel à tous les ingés Syntec ou assimilé : vous n'êtes sûrement pas au forfait jour, comme j'entends beaucoup de salariés dire. C'est la substance du jugement condamnant Altran cité dans ce journal, qui indique que c'était pour « non-paiement d'heures supplémentaires », mais sans expliquer comment c'est arrivé (si je me souviens bien de l'histoire) : c'est parce-que les contrats soit-disant « au forfait » de beaucoup de salariés ont été requalifiés (après avoir été poursuivis en justice) en contrats classiques car ils ne satisfaisaient pas du tout les conditions nécessaires (grande autonomie, responsabilités) et les obligations (niveau salaire), et que donc toutes les heures effectuées en plus de la durée légale du travail (35h) sur les deux ou trois dernières années ont été comptées en tant qu'heure supplémentaires. Je suppose qu'Altran a également accepté de requalifier ces contrats car ils ne voulaient se plier aux obligations salariales requises pour un vrai forfait jour : un salaire d'au moins deux fois le PMSS (Plafond_de_la_Sécurité_sociale https://fr.wikipedia.org/wiki/Plafond_de_la_S%C3%A9curit%C3%A9_sociale 39 732 € en 2018), soit environ 80 k€ par an…
Une très bonne lecture sur le sujet : https://blog.zwindler.fr/2017/12/12/convention-syntec-le-cadre-autonome-au-forfait-jour/
[^] # Re: Terminologie
Posté par benoar . En réponse au journal Une bosse sur la ligne pour combattre le bufferbloat ?. Évalué à 2.
Non, c'est l'inverse, le but n'est pas de dire qu'un ralentisseur ralentit ton trafic, mais qu'un mécanisme « élève » (du verbe « to bump ») ton trafic réseau (le titre original est « A little bump in the wire that makes your Internet faster »). Ça a moyennement du sens ici pour la modification de scheduling, mais à l'origine c'était pour l'ajout d'un header IPsec (qui élève le contenu du paquet original).
# Terminologie
Posté par benoar . En réponse au journal Une bosse sur la ligne pour combattre le bufferbloat ?. Évalué à 8. Dernière modification le 10 août 2018 à 15:41.
Le terme « bump-in-the-wire » devrait plutôt être traduit, je pense, par « élévation sur la ligne », ou un truc du genre. Ça vient du monde IPsec, cf. https://en.wikipedia.org/wiki/Bump-in-the-wire qui référence la RFC 4301 https://tools.ietf.org/html/rfc4301 mais on peut remonter à la RFC 2767 https://tools.ietf.org/html/rfc2767 qui cite un papier de 1996 (sur une implémentation MS-DOS d'IPsec !!). On en parle par opposition au « bump-in-the-stack », ou « élévation dans la pile », dans lequelle c'est la pile logicielle qui est modifiée pour inclure l'amélioration ; de sécurité dans le cas d'IPsec, ici de réactivité, même si le « bump » est lié à l'ajout d'un header IPsec AH/ESP dans le premier cas et n'a pas ici vraiment de sens. On en parle également dans les différentes méthode de transition IPv4/IPv6.
Quant au bufferbloat, on pourrait éventuellement dire « ballonnements dû aux tampons » ; bon, je suis vraiment mauvais en francisation je crois.
Le pire est que l'industrie des télécoms toute entière refuse toujours obstinément de reconnaître ce problème, et le poids de l'existant est tellement énorme qu'il est en effet aujourd'hui impossible d'avoir une infrastructure DSL avec des tailles de buffer correctes, tellement c'est enraciné dans les équipements et les gens.
# Les mdp chiffrés ne permettent pas les protocoles d'authentification interactive classiques
Posté par benoar . En réponse au journal Freenaute, ton mot de passe d'abonné est stocké en clair chez Free. Évalué à 10.
À chaque fois c'est le même débat qui tourne en boucle, sans jamais personne qui n'ait réellement eu entre les mains un tel système à gérer…
Avoir des bases de mot de passe chiffrées empêche toute authentification interactive « classique », qui permet de ne pas faire circuler le mot de passe sur le réseau, genre CHAP (rappelez-vous que Free à la base offrait des accès RTC où on s'authentifier avec du CHAP sur PPP…). Idem pour toute authentification interactive incluse dans EAP, pour reprendre un protocole un peu plus moderne. C'est également, je pense, une raison pour laquelle les gens semblent aimer le LDAP qui impose la méthode d'authentification avec une méthode de hashage fixée, et ne permet pas l'authentification interactive comme le permettrait RADIUS, qu'on mettrait normalement devant un LDAP.
Certes, aujourd'hui pour palier à la non-confidentialité des protocoles de vérification de mot de passe faisant passer le secret en clair comme PAP et pratiquement toutes les authentifications web « modernes », on ajoute du TLS en dessous et « tout va bien » ; c'est valable aussi bien pour le web que pour tout un paquet d'autres protocoles (comme EAP-TLS pour celui cité ci-dessus). Mais ces protocoles d'authentification sans gestion de la confidentialité étaient à l'origine pas très bien vus, et tous basés sur le principe de partage de secret identique, sans challenge.
Sans parler du fait qu'il existe des protocoles modernes (d'ou mon qualificatif de « classique » utilisé plus haut, par opposition) basés sur les mot de passe fait expressément pour ne pas avoir de base en clair, comme SCRAM https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism mais que tout le monde a l'air de s'en foutre.
Et bien sûr, tout cela en évitant l'éléphant dans la pièce : pourquoi a-t-on toujours autant d'histoires de mot de passes, avec une croissance et une complexité grandissante dans leur gestion, quand depuis des décennies on annonce l'avènement de l'authentification par cryptographie asymétrique ?!
[^] # Re: Kate
Posté par benoar . En réponse au journal Fins de tabulation élastiques: la bonne manière d'indenter et d'aligner le code. Évalué à 3.
Ce qui est exactement le fonctionnement d'une tab normale tel qu'implémenté dans tous les éditeurs depuis 30 ans. Ceci n'a rien à voir avec les tabulations élastiques, tu te méprends.
N'importe quel éditeur de texte qu'il soit « traitement de texte » ou pas a ce comportement que tu présente. Va vérifier. Encore une fois, rien à voir avec les tabulations élastiques, qui concernent le fait de faire de l'alignement de lignes adjacentes avec uniquement une seule tab (ce qui n'est pas le cas de ton exemple).
[^] # Re: Kate
Posté par benoar . En réponse au journal Fins de tabulation élastiques: la bonne manière d'indenter et d'aligner le code. Évalué à 6. Dernière modification le 30 juillet 2018 à 15:32.
Heu… c'est exactement le comportement d'une tabulation normale. Rien d'étonnant là-dedans.
# Gniibe préfère aussi le hard générique et documenté
Posté par benoar . En réponse à la dépêche Gnuk, NeuG, FST-01 : entre cryptographie et matériel libre. Évalué à 5.
J'ai lu (il me semble) dans les publications de Gniibe qu'il préférait également l'utilisation d'un STM32 « standard » plutôt que d'un autre chip spécialement orienté crypto avec des fonctions « spécialisées » (et fermées), car il expliquait qu'on ne sait jamais ce que ça cache, et que ça finit toujours par être craqué un jour. Il est très orienté « liberté avant le reste », et comme tu le dis bien, la liberté et la documentation est préférable à tout autre argument de sécurité, même si le choix peut sembler moins sécurisé au début. Je partage cet avis aussi.
Et pour l'anecdote, j'ai connu GnuK à l'époque où pour le tester seul le kit Discovery STM8S était vraiment accessible niveau prix (et ça le reste encore : 7,55 € chez Farnell, mais la différence avec le F103 est négligeable aujourd'hui) :
https://www.st.com/en/evaluation-tools/stm8s-discovery.html
Oui, le chip est un 8 bit, mais le chip qui fait l'interface UART-USB est un STM32F103, beaucoup plus puissant que la cible en question… Il contient moins de flash que le kit Nucleo, mais Gniibe a rajouté un hack car à priori, il aurait plus de flash que ce qu'indique la datasheet (perso, j'ai un patch pour désactiver des bouts afin que ça tienne dedans). Bon, ça reste un peu galère (en plus du port USB B assez gros), et je suis passé par un BusPirate pour le flash SWD, mais c'est drôle et pas cher.
# Avoir confiance au fail-over forcément *dans les deux sens*
Posté par benoar . En réponse au sondage Oui j’avoue, ma plus grosse boulette c’est d’avoir :. Évalué à 5.
En bossant sur les LNS de FDN, où arrivent toutes les connexions ADSL, je testais le fail-over de L2TPNS avec mes modifications pour annoncer les LNS en BGP aux routeurs upstream. Bien sûr, je teste depuis une ligne ADSL de chez FDN. Les deux serveurs sont up, les connexions sont réparties sur les deux, je coupe le premier : victoire, celles sur le premier basculent sur le second, ça fonctionne bien ! C'est vraiment époustouflant comme mécanisme, c'est quasi-instantané (quelque secondes) et toutes les lignes (environ 250 à l'époque, je crois) migrent sans problème. Confiant dans le système, je redémarre ce premier serveur, et « pour la forme » teste en coupant le second : allo ? Ya quelqu'un ? Ah, le fail-over n'a pas l'air d'avoir marché dans l'autre sens… Toutes les lignes sont tombées, y compris la mienne, et ça n'a pas l'air de redémarrer.
Bien sûr, on est dimanche soir minuit, et je n'ai donc plus d'accès au Net. Je ne suis pas à Paris ni Amiens, mais heureusement geb est dans le coin, lui pourra sûrement m'aider, je pars toquer à sa porte. En arrivant chez lui, il rigole bien, à priori la nouvelle s'est répandue assez vite sur IRC. C'est un autre Benjamin (bien nommé pour un dimanche) qui a vu la coupure et a redémarré les serveurs le temps que je fasse ma petite marche.
J'ai aussi appris plus tard par Domi que j'aurais pu me logger sur les serveur avec un realm et un login propre à notre fournisseur le collecte, vu l'architecture assez « open » du DSL en France.