Antichesse (o ^ω^ o)
J'adore ce genre d'article. Il s'agit d'un "bug" hein, mais pas d'une tentative pour Microsoft de récupérer nos données confidentielles de navigation en dehors de tout cadre RGPD.
D'ailleurs, c'est tellement un "bug" que le code de Edge a été modifié pour envoyer toutes les URL visitées à l'adresse https://bingapis.com/api/v7/followweb/isfollowable*?, malgré les procédures de test et de contrôle qualité misent en œuvre chez Redmond.
Et puis c'est tellement un "bug" qu'à cette adresse a été développé un serveur dédié à la récupération de ces informations confidentielles de navigation pour les y stocker et les analyser.
Enfin, c'est tellement un "bug" que dernière cette adresse a été montée une infrastructure matérielle monstrueuse capable d'encaisser la charge de dingue que l'envoie de toutes ces données confidentielles de navigation implique.
Repense au passif de Microsoft et à la vie privée... Se dit que prétendre à un "bug" peut lui éviter un procès pour violation du RGPD... Doit faire partie des conspis, Microsoft est trop honnête n'est-ce pas ...?
Je réagis sur ça @Timo :
En tant que programmeur, je sais qu’il est utile de commenter son code pour ce genre de chose : quand on corrige un bug très rare, il faut noter le bug et pourquoi on a remplacé un code simple et trivial par un code sale et compliqué (mais corrigeant le bug). C’est pas parce qu’on est con qu’on a changé un bon code pour un code pourri : c’est parce qu’on y a été forcé. Et le commentaire sert à alors à éviter que, cinq ans après, on ne soit tenté de revenir en arrière car le code est moche et sale et qu’on préfère la solution propre, en ayant oublié qu’il était bugué.
Non pas un commentaire mais à la place un ou plusieurs tests unitaires reproduisant le problème.
Ces tests seront joués automatiquement et systématiquement à chaque construction et le moindre échec sera build-breaker.
Si tu souhaites un exemple te montrant comment faire en PHP, JS, TS, Kotlin, Java, Rust, Go ou Python n'hésite pas à me demander <3
Plusieurs PC avaient été touchés suite à la mise à jour des Linux début décembre. Comme le bug d'accès aux boites email d'Office 360 était arrivé en même temps, nous étions passés au webmail fourni en supposant que cela venait d'une nouvelle version de Thunderbird.
Pourquoi je ne suis pas étonnée d'apprendre que cela vienne de chez Microsoft ? Ah oui, l'habitude depuis toutes ces années...
Nous sommes à la mi 2022 et la Caisse d'Épargne n'est toujours pas fichue d'employer des développeurs qui comprennent qu'on ne peut pas partager des requêtes avec des sous-domaines lorsque l'on active le contrôle de sécurité Same Origin !
Blocage d’une requête multiorigine (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur https://www.as-ex-ano-groupe.caisse-epargne.fr/api/oauth/v2/token. Raison : échec de la requête CORS.
Blocage d’une requête multiorigine (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur https://fonts.gstatic.com/s/ubuntu/v20/4iCv6KVjbNBYlgoC1CzjsGyN.woff2. Raison : échec de la requête CORS.
downloadable font: download failed (font-family: "Ubuntu" style:normal weight:300 stretch:100 src index:0): bad URI or cross-site access not allowed source: https://fonts.gstatic.com/s/ubuntu/v20/4iCv6KVjbNBYlgoC1CzjsGyN.woff2Et tout leur site est bloqué pour un pauvre token et deux polices de caractères ! Mais leurs développeurs / sous-traitant sont nuls ! C'est incroyable que le B.A.BA ne soit pas maîtrisé à ce point. On se croirait chez ERDF / Enedis (ceux qui y sont passés doivent me comprendre) #FacePalm
Edit : en fait le site a été conçu pour Chrome et je suis sous Waterfox (une fork de Firefox sans les problèmes inhérents à Mozilla / Google). Bref, des polyfills JS sont chargés et font du cross-origin et forcément personne n'a lancé un Firefox like pour vérifier que ça marche...
À toutes ces personnes qui font du spécifiques Chrome je souhaite que ça vous gratte en permanence et à mort quelque part et qu'à chaque fois que votre doigt s'approche du point qui vous démange, celui-ci se déplace !
Je développe une lib en Kotlin (jusque là normal) et disposant de deux PC, il m'arrive de démarrer le travail sur l'un et de le finir sur l'autre (encore une fois normal). Sauf que... Sur mon PC portable, que nous appellerons le PC-P, impossible de compiler la même lib au même numéro de commit (une erreur obscure émane du JDK lui-même) alors que sur mon PC fixe, que nous appellerons PC-F, aucun problème.
C'est partie pour l'enquête ! #StoryTime
1) Mes outils ne sont pas à jour sur l'un des deux postes
Le PC-P ayant les dernières versions mais pas le PC-F, j'aligne le tout (OpenJDK, Intellij, OS, Maven, etc) dans les dernières versions disponibles et non, même résultat. PC-F ça marche, PC-P ça plante !
2) J'accuse le répo local de Maven.
Je drop l'intégralité du répo sur les deux machines, je rebuild avec les mêmes lignes de commande, rien n'y fait.
3) J'accuse le compilateur Kotlin.
Ayant fait une montée de version vers la 1.3.72 je me dis que cette toute dernière version est peut-être instable. Du coup je décrémente sa version à la 1.3.41. Toujours ce fichu problème (il s'agit un JVM access FileNotFound au passage - erreur que je n'avais jamais vu de ma vie).
4) J'accuse mon code
Aparté : oui seulement au bout de 4 étapes mais les trois premières ne me demandaient pas beauoup d'effort.
Je reviens en arrière surun commit, deux commits, cinq commits, 17 commits plus loin et ça marche enfin sur les deux... Sachant que tous mes commits ont été stashés et squashés vous n’imaginez pas le nombre de lignes modifiées... #Pleur
Après investigation, j'arrive au point où j'identifie une classe de test mais plante-t-elle à la compile ou au run ? Je commence à lancer un mvn test-compile et ça marche. Je lance un mvn test et ça pète mais toujours pas d'indice.
#FastForward Il se passe une nuit et j'en parle à @Lenny le lendemain. Il teste sur son poste et lui-aussi sa plante. Sauf qu'ayant une version plus ancienne de Mint mais aussi du JDK il voit un message différent du mien : un FileNotFound qui indique une classe, précisément classDeTest$NomDeMethod.class (ce sont les classes virtuelles que créé Java).
Je lui demande de prendre tout le chemin de fichier et d'effectuer un touch (car le chemin à l'air assez long) et le touch pète ! #PremièreVictoire
=> Conclusion rapide : le chemin de fichier est trop long. Mais alors pourquoi est-ce que ça marche sur mon PC-F et pas sur mon PC-P !!? #WTF
... Petit moment de suspense... Ur ur ur (^__^)
Réponse :
Le PC-P de @Lenny tout comme le mien ont une partition Ext4 chiffrée ! Or mon PC Fixe a une partition en clair et il faut savoir qu'une partoche Ext4 en claire permet des chemins de fichiers de 255 caractères tandis qu'une Ext4 chiffrée est limitée à 143 caractères ! Le voilà notre coupable...
Vous n'avez pas idée des heures que j'ai perdues à cause de ce comportement mais je suis tellement contente d'avoir trouvé !
@Animal c'est pour toi !
La faille de sécurité qui touche OpenPGP émane d'un défaut dans le design d'OpenPGP lui-même. Cerise sur le gâteau, personne n'est mesure de corriger ce problème car le code qui gère cette partie d'OpenPGP est très complexe et surtout, il a été écrit... en OCaml... #FacePalm
Ce langage nous suivra jusqu'à la fin de notre vie je crois. Je n'imagine même pas la dette technique que les outils codés en Scala vont engendrer à terme (car il s'agit du même phénomène, Scala étant un peu plus répandu que OCaml mais tout aussi difficile).
Via Librement Shaarli.
Je ne l'aurai pas vu et entendu, je ne l'aurai pas cru ! Et oui, le nouveau meme de l'incompréhension 2019 sera le visage du mec en jaune.
Apparemment le coup du bug de l'an 2000 revient avec les GPS le 6 avril 2019. Les mecs auraient codé les dates sur 10 bits... #Bravo #Genius
Non seulement l'humanité n'apprend pas, mais en plus elle refait les mêmes erreurs sur des systèmes ultra-critiques pour ses économies mondiales. En effet, puisque fin des GPS => fin des échanges financiers sécurisés.
Quel est le rapport avec la choucroute ?
Simplement que pour qu'une transaction se fasse, il faut que les horloges soient synchronisées et que les protagonistes soient localisés afin de caler leur heure sur le bon fuseau en temps UTC.
Si vous n'êtes plus capables de vous localiser, mieux encore de prouver votre localisation au tiers avec qui échanger, alors vous ne pouvez plus échanger (du moins sans risquer un vol).
C'est une des conséquences du GPS mais il y en a tellement d'autres.
Via le styx
Il m'était arrivé une chose similaire dans une Peugeot 207 il y a 8-10 ans ! J'étais en voiture avec Roudoudoutte et nous partions en vacances. Cela faisait quelques heures qu'elle roulait et elle m'avait passé le volant. Le régulateur de vitesse était fixé à 70 Km/h et nous étions arrêtées en aglo pour le changement sur une place de stationnement, le long d'un trottoir.
Là, grosse trouille puisque au moment où je commence reprendre le véhicule et à accélérer, la voiture se met à monter toute seule très vite et très fort dans les tours, alors que je n’accélère plus hein, ceci pour rejoindre les 70 Km/h. J'ai beau désactiver le régulateur, rien n'y fait. C'est après avoir écrasé pour la troisième fois la pédale de frein que tout le système cessera de s’emballer.
L'idée de Daniel de débrayer n'avait pas fonctionnée... Bah oui, les Peugeots savent changer les vitesses toutes seules...
In MySQL, never use “utf8”. Use “utf8mb4”. – Adam Hooper – Medium - kalvn's links - Liandri's Links.
Je résume ici :
- Dans MySQL, l'encodage appelé utf_ (ou utf8_general_ci) n'est pas de l'UTF-8.
- En réalité, il s'agit d'une implémentation partielle de l'UTF-8 limité à trois octets.
- Cela peut poser problème, voir corrompre vos données si vous faites de l'UTF-8 end-to-end.
- A la place de l'encodage 'utf8', choisissez 'utf8mb4' qui est une vraie implémentation du format.
Je précise aussi qu'il faut utiliser la collation utf8mb4_unicode_ci à la place de utf8mb4_general_ci car le tri alphabétique y respecte la langue de la région employant les caractères particuliers.
Tout est dans le titre est l’explication en lien.
Contexte de l'erreur, vous observez cette sortie dans le WikiLeet de votre console : java.io.IOException: User limit of inotify watches reached
Ce qui signifie que le FileWatcher utilisé par l'outil a atteint les limites que lui confère l'OS (dans notre cas un Linux).
Comment connaître le nombre maximum de fichiers "watchable" par un Linux :
cat /proc/sys/fs/inotify/max_user_watches
8192Comment doubler cette valeur :
sudo echo "16384" > nano /proc/sys/fs/inotify/max_user_watchesCorriger un bug dans un projet open source sous GitHub.
Via je ne sais plus qui.