Note : billet très technique, je n'ai pas forcément les connaissances pour bien l'appréhender.
Un message concernant les risques possibles à utiliser l'outil Address Sanitizer (ASan https://en.wikipedia.org/wiki/AddressSanitizer) dans un environnement de production, comme une élévation de privilège puisque ce dernier peut exécuter du code binaire avec setuid sans vérifier les variables d’environnement.
Le problème avec la fin du Réseau Téléphonique Commuté (RTC), ce sont les personnes qui ne sont pas technophiles, comme les personnes âgées, qui ne pourront plus téléphoner sans devoir débourser encore une fois pour changer leur équipement, ni les problèmes qu'il existe en cas de coupure de courant, comme pour les services d'urgence comme l'indique l'article.
Encore une fois, cela va créer plus de problèmes que ça n'en résout, uniquement au nom de la sacro-sainte finance.
Un brouillon concernant TLSv1.3.
D'ailleurs, pour pouvoir profiter de Forward-Secrety, il suffit de retirer le chiffrement RSA pour l'échange de clefs symétriques, avec "!kRSA", comme ceci (liste fonctionnant avec OpenSSL en version 1.0.2f actuellement) :
HIGH:!kRSA:!DHE:!DH:!SSLv3:!SSLv2:!RC4:!aNULL:!eNULL:!EXPORT:!3DES:!DES:!SHA1:!MD5
Pour retirer le chiffrement AES128, il suffit de rajouter ":!AES128" à la liste, mais les navigateurs actuels ne fonctionnent pas sans.
Quelques arguments sur pourquoi Bitcoin n'est pas une valeur sûre, pas en terme de rentabilité mais en terme d'utilisation, pour le « commun des mortels ».
Les “early adopters” et les centraliseurs sont ceux qui ont pu s'en mettre un max dans les poches.
À fuir.
Oh, voilà un message juste et intelligent, concernant les erreurs du passé.
Oh … Aïe, quoi. Ça a l'air plus que sérieux …
C'est étrange, ça rappelle énormément la faille GHOST, en janvier 2015, soit un an : https://links.thican.net/?Y8L6Ag
Plus de liens :
- en français sur le site Web Developpez.com : http://www.developpez.com/actu/96101/Une-autre-faille-critique-de-securite-a-ete-decouverte-dans-glibc-et-rend-les-machines-sous-Linux-vulnerables-a-l-execution-d-un-code-a-distance/
- https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
- en français sur Linuxfr.org https://linuxfr.org/users/bortzmeyer/journaux/faille-de-securite-dans-la-gnu-libc-avec-les-requetes-dns
À première vue, effectivement, ça semble être une décision regrettable (dans ce que je vais expliquer, ne prenons en compte que les adresses IPv4).
L’une parce que des clients vont être lésés de ne pas avoir de plage complète de ports, et l’autre parce « [qu’]avec environ 11 millions d’adresses IP[v4] pour 6 millions de clients », il y a mathématiquement beaucoup de la place restante. Or, c’est voir le problème par le bout de la lorgnette.
Déjà, commençons par le vif du sujet, le partage de ports : il est de faits que la grande majorité des clients n’utilisent absolument pas de ports ouverts dans leur CPE (les « box ») pour héberger des services chez eux. Du coup, passer de 64ki ports, soient 65 536 ports (1 ki = 1024 unités) pour n’avoir que le quart, soient 16 384, n’empêchent absolument pas de pouvoir naviguer tranquillement sur Facebook, Twitter, Tinder, NetFlix, et d’autres services superflus comme les jeux vidéo, bref, « l’Internet » pour cette majorité de gens. Ces 16 milles ports sont bien plus que suffisant même pour plusieurs utilisateurs derrière la même connexion. De plus, rien n’empêche (si j’ai bien compris) d’ouvrir tout de même quelques ports parmi vos 16ki ports disponibles, pour avoir des services derrière votre CPE grâce au NAPT.
Concernant le nombre théorique d’adresses encore libres, c’est ne pas prendre en compte que les équipements chez Free, comme les routeurs de “backbone” ainsi que les DSLAM, ne peuvent pas prendre une adresse IP parmi les adresses théoriquement disponible : il y a un découpage à respecter, sans parler des adresses qui ne peuvent pas être assignées car elles ont un rôle particulier. Par conséquent, des tas d’adresses IP sont ainsi figées, et redéfinir ces découpages n’est pas chose aisée, surtout que ça voudrait dire que des clients actuels perdraient leur adresse actuellement assignée.
Mais au final, il y a des solutions : si vous faites parti des très rares à 1) avoir besoin d’ouvrir des ports, et 2) dans une plage spécifique (comme c’est le cas pour un service Web qui utilise par défaut les ports 80 et 443, ou pour héberger vos courriels avec les ports 25 et 465), Free a tout de même penser à vous, en fournissant des « adresse IP fixe ». Pour l’instant, pas d’infos sur les modalités d’acquisitions, le prix, etc., mais cette option règle complètement le problème.
De plus, c’est ignorer le fait que ce problème ne concerne qu’IPv4, qui tend à être remplacé par IPv6 ! Sans faire un cours sur IPv6, ce dernier crée des adresses sur 128 bits (dont 64 réservés pour la partie réseau), là où IPv4 ne fonctionne « que » sur 32 bits, ce qui permet d’avoir une quantité immense d’adresses supplémentaires (pas un facteur 4, mais plus !).
Ainsi, chaque client pourra avoir au minimum un /64 pour chaque connexion, ce qui ne permettra plus de problème de partage. Encore une preuve de la très proche pénurie d’adresses en IPv4, et qu’il est temps de fonctionner entièrement en IPv6.
Pour conclure, ce problème n’en est pas un. Le problème de base reste être la pénurie d’adresses en IPv4, et que le déploiement en IPv6 doit être obligatoire. Free est conscient d’un réel soucis et est juste pragmatique vis-à-vis de ses clients.
Certes, d’autres problèmes subsistent (comme les pings en ICMP, ou globalement les protocoles au dessus de la couche IP qui fonctionnent sans port), mais encore une fois, ces cas particuliers car rares ne devraient pas être les fonctionnements par défaut.
« Après analyse scientifique, seuls 11 coups de feu sont attribués aux terroristes contre près de 1500 du côté de la police d'élite. »
« Pire encore : certains policiers sont blessés par leurs propres collègues. Même le chien policier, Diesel, aurait été tué par erreur. »
Hé ben, pas brillant ; pire même, vu les honneurs qui ont été fait médiatiquement, alors que de nombreux doutes planaient déjà aux lendemains de cet assaut.
Dans cet article, un homme découvre que sa femme est enceinte à partir des données de son bracelet électronique, qui mesure l'activité cardiaque et plus.
Voilà un bon exemple pourquoi il est très important de ne pas fournir aveuglément les données concernant notre propre santé à des entreprises privées, qui sont très friandes de ce genre de données pour vouloir nous vendre plus de produits soient disant plus adaptés à nos besoins, besoins majoritairement créés.
Via le blog de Bruce Schneier https://www.schneier.com/blog/archives/2016/02/fitbit_data_rev.html
Sujet intéressant et détaillé concernant les avantages et les inconvénients de systèmes basés principalement sur un modèle dit de “BlockChains”.
Il existe un préfixe en IPv6, qui permet d'écrire des adresses IPv4, pour ainsi faire de la traduction d'un réseau uniquement en IPv6, vers l'internet en IPv4 (oui, il faut donc une machine qui sont reliée en IPv4 pour faire la traduction, principe appelé NAT64).
C’est dans la section 2.1 qu’est définit le préfixe :
“The value of this IPv6 prefix is: 64:ff9b::/96”
À garder sous le coude, pratique d'avoir de quoi pouvoir illustrer ses propres articles.
Via SebSauvage: http://sebsauvage.net/links/?uKJNJg
Un article intéressant sur les problèmes que nous risquons encore de rencontrer, à se reposer uniquement sur un seul et unique outil, le tout sur un réseau centralisé, sans oublier que ce dernier est basé sur un logiciel propriétaire.
De mon côté, principalement parce que mes projets ne concernent que moi, je m'efforce d'autohéberger mes propres projets, puis d'utiliser le gestionnaire de sources Mercurial, pas par esprit de contradiction, mais parce que je trouve que cet outil répond tout à fait à mes besoins (je n'ai pas réussi à voir les différences concrètes entre git et mercurial).
Haha, tiens, je ne connaissez pas. Un indicateur clair si le discours est sincère ou parodique.
En français : https://fr.wikipedia.org/wiki/Loi_de_Poe
Oh, j'aime beaucoup cette proposition de loi, je la trouve très utile, comme expliqué dans l'argument de Michèle Bonneton (EELV), repris dans l'article.
Certes, ça fait encore un manque à gagner pour les chaînes publiques, mais il y a d'autres solutions.
Me concernant, c'est la raison numéro 1 pour lesquelles je déteste développer pour du Web ; puis rajouter le CSS qui devient lourd et compliqué pour avoir un résultat convenable, puis le PHP que je n'aime pas (oui je sais que côté serveur, il existe d'autres outils), voilà le cocktail abrasif qui rend le développement Web pénible, et par conséquent rend ses développeurs non sérieux vis à vis de la maturité de leurs travaux.
L'informatique, ce n'est pas l'humain qui doit asservir la machine, mais la machine qui doit asservir l'humain.
Pour se détendre un peu, un sketch humoristique de Michael Davis
https://en.wikipedia.org/wiki/Michael_Davis_%28juggler%29
Au détour d'un lien sur le web, un matériau qui absorbe 99,965 % de la lumière visible.
Du coup, on ne peut pas voir une quelconque forme sur sa surface ; j'aurais même peur d'y poser ma main dessus. :D